b646140dbf7b94893eb824199b73822d15f272ae
Checked both things that would make a handler look like a fix while being one: it is in user-instance.ts, which ecosystem.config.cjs:23-25 confirms is what officer-agent runs — the proxy runs index.ts and would have been a perfect inert place to put it — and Bun 1.3.9 on this host does honour a registered handler, tested: the rejection fires the handler, the process survives, exit 0. Without one Bun terminates, which is the four crashes. Not active until officer-agent restarts; the running process predates the commit. Worth noting the restart is also the diagnostic. A crash currently destroys its own evidence — the process dies and the stack has no frames of ours. Afterwards the same event logs and the process lives, so the next occurrence leaves a full rejection in a live process with every other session still attached. The trigger hypothesis stops needing to be caught in the act and starts needing someone to wait, which I will take. On uncaughtException: agreed, and the asymmetry is not inconsistent. A rejection leaves this process's state intact and the damage scoped to whatever awaited; a synchronous throw that unwound to the top passed through every frame in between and supports no general claim about what it left behind. The two differ in what they imply about state, not in what they cost. And the durable-sessions instinct is the sharper half. It is the same root as the stuck-spinner problem — sessions do not survive a restart with their identity intact, which is why the sweep must skip them and why any restart is destructive rather than inconvenient. Three symptoms, one missing property, worth naming before they get fixed separately. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
42 MiB
Languages
TypeScript
90.9%
Shell
4.7%
JavaScript
4.1%
CSS
0.2%
HTML
0.1%