[Frontend] — Route Error Boundary Retry and Report

[Olowodarey]

Problem
route-error-state shows a generic error with no retry or way to report, forcing a full reload after any route failure.

Requirements

• "Try again" that re-runs the failed route loader without full reload.
• "Report issue" prefilled with the error digest.
• Distinguish 404 (app-not-found) from runtime errors.
• Tests: retry re-invokes the loader; report link includes the digest.

Acceptance Criteria

• Users recover from route errors without reloading. Covered by tests.

Files

• frontend/src/component/route-error-state.tsx
• frontend/src/component/app-not-found.tsx
• frontend/src/app/error.tsx

[bilhokista]

I have opened #1794 for this issue.

One of the four requirements was already satisfied, so I want to be clear about what I did and did not change. "Try again that re-runs the failed route loader without full reload" already works: the button is wired to the reset prop, which is Next.js's own boundary reset, and the existing test already asserts it is invoked. I left that alone rather than reimplementing it.

The two genuinely missing pieces:

Report issue. A new action opens the tracker with the context prefilled, built by two pure functions so they can be tested without the DOM. It handles both a tracker URL (title/body) and a mailto: address (subject/body), and appends correctly when the base URL already has a query string. I deliberately left the stack trace out, since a stack can carry values from the failing request and this text is handed to a third party; the digest, message, route and timestamp are enough to correlate with server logs.

404 versus runtime errors. A route calling notFound() lands in the same boundary as a genuine crash, so a mistyped URL was showing "hit an unexpected problem" with a Try again button that could never succeed. Those now render the existing AppNotFound. The detection is deliberately narrow — Next's NEXT_NOT_FOUND digest and an explicit numeric 404 status, not the substring "404" in a message, which would misroute a real failure that merely mentions a 404 sub-resource. There is a test for that case.

One judgement call I would like your view on: the report destination reads from a new NEXT_PUBLIC_ERROR_REPORT_URL, defaulting to this repository's GitHub issue tracker. That is right here but a fork would want its own, hence the variable. If you would prefer the action be hidden when nothing is configured, that is a small change.

The test file goes from 1 case to 18.