Product

Commands in containers lost their output for twelve days

Since 11 September, a command in a container that took longer than half a second came back empty and marked as successful. It is fixed, and a failed stream can no longer look like success.

What went wrong

A small relay between our server and Docker closed each connection half a second after the request was sent. Anything a command printed after that was lost, and the exit code came back as 0. For the model this looked like a command with nothing to say: pip seemed to do nothing, builds seemed to pass. Reading a file through the chat had a second fault. Files larger than about 75 KB arrived shortened but were reported as complete, so an edited file could lose its end when written back.

Both are fixed. Every command now reports its own end, and a missing report says the output may be incomplete instead of claiming success. File reads and writes compare the size on both sides. If you worked in a container between 11 and 23 September and a file looks cut off, check it against your last copy.

Android 1.19.1

Phone tools now check what they did before reporting it. Unlocking waits until the lock screen is really gone, opening an app checks that it is in front, and tapping Send checks that the message field emptied. The zerolog.ch tab signs in with the app's own pairing and no longer stays black. Typing a slash lists the commands, and a PIN entered with /unlock-pin is masked in the history. Download.

Corrections are entries here too. If something on this page is wrong, say so. Feed · Docs · Legal & privacy · Home