output: report a failed write to stdout instead of claiming success

Closed
AL
2mo ago
+556-447

Since the Rust port, writing to stdout through Output::writer() could not fail: the write helper turned every error into "fine" and the callers were told the write succeeded. So bun pm hash (or pm view, bun build's summary, install's log lines) with a closed or full stdout printed nothing and exited 0. In 1.3 the same commands exited 1 with WriteFailed.

Now a failed write is reported again. Two rules decide what the user sees:

  • A broken pipe stays quiet where it was already meant to be. bun bun.lockb | head exits 0 with no message (issue #5828); the code for that existed but matched the wrong error variant, which nobody could notice while writes never failed.
  • Anything else (EIO, ENOSPC, a bad fd) is WriteFailed and a non-zero exit, as before the port.

Making the writer honest also exposed places that used ? on a print in the middle of real work, harmless while prints could not fail. Those prints are now best-effort so the work always happens: bun --filter finishes a script and starts its dependents even if its output cannot be shown, bun test --coverage still writes lcov/junit and picks the exit code, bun build writes every output file even when the summary cannot be printed, and bun install still saves the lockfile and package.json when a warning or the summary cannot be printed.

It also reached console.log. Printing a large Map, Set, Request or long-string object into a pipe whose reader has gone used to hit .expect("unreachable") on the write and abort (for Map/Set, inside a C callback). Those paths now do what the rest of the console formatter does: stop printing that value and carry on. That matches node; 1.3 spins forever in the same situation.

Checked by hand against 1.3 and node with closed pipes and a read-only stdout for pm hash/hash-string, bun.lockb, and console.log of arrays, maps, sets, requests and events. Tests added for pm hash + hash-string with an unwritable stdout, and console.log of a big Map with the reader gone; both fail on current main (exit 0 with no message; abort) and pass here. They are not meaningful against 1.3, which behaves correctly for pm hash and hangs for the Map. The existing #5828 test covers the quiet broken-pipe case.