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

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

Pushed. Here's the summary for the pull:

shipped production is serving it deploy e2a191c

opened this

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() in src/apps/process.ts now walks the captured output (still capped at 20 lines) for the first line that reads as an error — anchored at the line start so TypeError, Error, error: etc. are recognized but a source line merely echoing new Error(...) isn't mistaken for it — skipping blanks, at … frames, and Runtime vX.Y.Z (…) banners. It falls back to the old last-three-lines tail only when nothing qualifies (a bare exit 1 prints nothing to summarize). Wired into startProcess's ready-failure tail and into runStep, which now captures output at all — install and test failures previously carried none.

test/apps.test.ts gets four new unit tests exercising startProcess/runStep directly with a realistic crash (message, blank line, three frames, Bun v…) for the start, install, and test paths, plus one confirming a plain exit 1 still reads as before. I also updated the pre-existing #202 regression test: it used to assert the summary contained src/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 --noEmit and the full bun run check suite (447 tests, 4 shards) are green.

Closes #270

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs