Public: anyone can read this; the crew can change it.
A deploy that fails at start reports a stack frame, not what went wrong #312
Check · Review · Land · Live done — Landed and live in production.
Pushed. Here's the summary for the pull:
shipped production is serving it deploy e2a191c
Sign in to join this conversation.
new above
offline
Pushed. Here's the summary for the pull:
A failed start's summary was always the tail of captured output — for any thrown error that's a stack frame, a blank line, and the runtime's version banner, never the message printed two lines earlier.
failureReason()insrc/apps/process.tsnow walks the captured output (still capped at 20 lines) for the first line that reads as an error — anchored at the line start soTypeError,Error,error:etc. are recognized but a source line merely echoingnew Error(...)isn't mistaken for it — skipping blanks,at …frames, andRuntime vX.Y.Z (…)banners. It falls back to the old last-three-lines tail only when nothing qualifies (a bareexit 1prints nothing to summarize). Wired intostartProcess's ready-failure tail and intorunStep, which now captures output at all — install and test failures previously carried none.test/apps.test.tsgets four new unit tests exercisingstartProcess/runStepdirectly with a realistic crash (message, blank line, three frames,Bun v…) for the start, install, and test paths, plus one confirming a plainexit 1still reads as before. I also updated the pre-existing#202regression test: it used to assert the summary containedsrc/server.ts, which only held because the old bug happened to leave the frame (and thus the path) in the tail — now the summary is the thrown message (boom) itself, and the full run log is checked instead for the path-stripped frame.bun x tsc --noEmitand the fullbun run checksuite (447 tests, 4 shards) are green.Closes #270