Capture the handlers that never report
The three places errors escape entirely: unhandled rejections, uncaught exceptions, and the frontend error boundary.
The ticket
Register handlers for unhandled rejections, uncaught exceptions, and the frontend error boundary so nothing escapes unreported.
Acceptance criteria
- Each of the three paths is registered and reports
- A seeded failure on each appears in the tracker
- The error boundary shows a usable interface rather than a blank page
- Handlers do not swallow the process exit behaviour they should preserve
What lands as proof
Three seeded failures, one per path, each visible in the tracker with its stack.
Why teams defer it
- These paths fire rarely, so their absence is never noticed during normal work.
- A blank page from a crashed boundary looks like a slow load, so users refresh instead of reporting.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: register handlers for unhandled rejections, uncaught exceptions, and the frontend error boundary so nothing escapes unreported. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means one seeded failure per handler, each visible in the tracker, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.