setInterval(fanoutStatus, …) and void fanoutStatus() (worker.ts:278,280) drop a promise that rejects when the snapshot query throws. Nothing handles unhandledRejection, so Node 22 exits, and a full disk becomes a crash loop.
Fix
Add .catch at both call sites
Add a process-level unhandledRejection handler that logs
`setInterval(fanoutStatus, …)` and `void fanoutStatus()` (`worker.ts:278,280`) drop a promise that rejects when the snapshot query throws. Nothing handles `unhandledRejection`, so Node 22 exits, and a full disk becomes a crash loop.
**Fix**
- [x] Add `.catch` at both call sites
- [x] Add a process-level `unhandledRejection` handler that logs
Reviewed 96d21d0514. Both fix items are done, so I'm closing this.
Checklist
.catch at both call sites. The startup call and the interval callback now catch and log a failed status fanout (worker.ts:279,281-282). fanoutStatus is async, so a query that throws synchronously inside it still becomes a caught rejection. The new worker-scheduling test proves this for both the startup and the scheduled call, and that the next interval runs again.
Process-level logger.hooks.server.ts:16 registers an unhandledRejection handler that logs. After #65's change it's guarded so it registers only once, even when boot is retried (hooks.server.ts:19). The new hooks-server.test.ts checks it's registered once, before the workers start.
Review notes
The 5 affected test files pass locally (105 tests), the full suite passes (208 files, 2,625 tests), and npm run check reports 0 errors.
Reviewed 96d21d0514ccddccacbbf8619df01fb050f6e472. Both fix items are done, so I'm closing this.
**Checklist**
- [x] **`.catch` at both call sites.** The startup call and the interval callback now catch and log a failed status fanout (`worker.ts:279,281-282`). `fanoutStatus` is async, so a query that throws synchronously inside it still becomes a caught rejection. The new worker-scheduling test proves this for both the startup and the scheduled call, and that the next interval runs again.
- [x] **Process-level logger.** `hooks.server.ts:16` registers an `unhandledRejection` handler that logs. After #65's change it's guarded so it registers only once, even when boot is retried (`hooks.server.ts:19`). The new `hooks-server.test.ts` checks it's registered once, before the workers start.
**Review notes**
- The 5 affected test files pass locally (105 tests), the full suite passes (208 files, 2,625 tests), and `npm run check` reports 0 errors.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
setInterval(fanoutStatus, …)andvoid fanoutStatus()(worker.ts:278,280) drop a promise that rejects when the snapshot query throws. Nothing handlesunhandledRejection, so Node 22 exits, and a full disk becomes a crash loop.Fix
.catchat both call sitesunhandledRejectionhandler that logsReviewed
96d21d0514. Both fix items are done, so I'm closing this.Checklist
.catchat both call sites. The startup call and the interval callback now catch and log a failed status fanout (worker.ts:279,281-282).fanoutStatusis async, so a query that throws synchronously inside it still becomes a caught rejection. The new worker-scheduling test proves this for both the startup and the scheduled call, and that the next interval runs again.hooks.server.ts:16registers anunhandledRejectionhandler that logs. After #65's change it's guarded so it registers only once, even when boot is retried (hooks.server.ts:19). The newhooks-server.test.tschecks it's registered once, before the workers start.Review notes
npm run checkreports 0 errors.