A startup failure exits with a raw stack trace instead of the outcome line #57
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Everything that runs before
runWrapperis outside its error handler. A failure there prints Node's uncaught-exception output, with a file path into the bundle, a source line and a stack, and no outcome line or remedy.What happens
runWrappercatches errors and prints one line that names the outcome and the remedy (src/wrapper/orchestrator.ts:142-164). The setup inmain.tsruns before it: the forge credentials and repository slug at module scope (src/main.ts:15-22) andreadWrapperInputsas a top-levelawait(src/main.ts:27). A throw in either rejects the module.That covers a missing environment variable, an unsupported event name, a malformed
pr_number(src/wrapper/event-context.ts:47-61), a dispatch for a pull request that is merged, closed or of unknown state (src/wrapper/event-context.ts:74-88), and a failed forge read during a dispatch (src/wrapper/event-context.ts:123).Reproduced at
9f272a52with the committed bundle on Node 24.21.0 (s3-dispatch-fork-merged, and everys8rejection): a dispatch for a merged pull request printedfile:///…/dist/index.mjs:6239, thethrowline, the stack andNode.js v24.21.0, and exited 1.What it should do instead
Run input derivation inside the same handler, or catch it in
main.ts, so each of these ends with one line that names the cause and exits 1. The exit code stays as it is. Refusing a merged pull request is correct; only how it is reported changes.Why it matters
The outcome line is what a person reads first in the job log, and the failure table in the README promises one. A stack trace into a bundled file hides the cause (
pull request #7 is already merged) behind frames that name no source file. It has no security effect.🤖 Generated with Claude Code