feat(errors): report action with error digest and 404 detection

[bilhokista]

Closes #1565.

One requirement was already met

"Try again that re-runs the failed route loader without full reload" already works: RouteErrorState wires its button to the reset prop, which is Next.js's own boundary reset, and the existing test in route-error-state.test.tsx already asserts reset is invoked on click. I left that untouched rather than reimplementing it, and the existing test still passes unchanged.

The two genuinely missing pieces were the report action and the 404 distinction.

Report issue

A new "Report issue" action opens the tracker with the context prefilled. Two pure functions do the work so they can be tested without the DOM:

• buildReportBody(context) — route, path, digest reference, timestamp, and error message, followed by a prompt asking what the user was doing.
• buildReportUrl(baseUrl, context) — appends the parameters, using title/body for a tracker URL and subject/body for a mailto: address, and appending correctly when the base URL already carries a query string.

Two deliberate choices:

• The stack trace is left out. A stack can carry values from the failing request, and this text is handed to a third party. Digest, message, route, and time are enough to correlate with server logs.
• A missing digest is written as Reference: none, rather than omitting the line. An absent field reads as an oversight; an explicit "none" tells the maintainer the error genuinely arrived without one.

The link opens in a new tab, so an in-flight recovery attempt on the page is not thrown away.

Distinguishing 404 from runtime errors

A route that calls notFound(), or a loader surfacing a 404 from the API, lands in the same error boundary as a genuine crash. Until now both rendered "hit an unexpected problem" with a Try again button — which for a mistyped URL invites the user to retry something that can never succeed.

isNotFoundError now routes those to the existing AppNotFound component. It is deliberately narrow: it matches Next's NEXT_NOT_FOUND digest and an explicit numeric status/statusCode of 404, not the substring "404" in a message. A substring match would send a real failure whose message happens to mention a 404 sub-resource to the wrong screen; there is a test for exactly that case.

A missing page is also no longer logged via console.error as an application fault.

Configuration

env.ERROR_REPORT_URL reads NEXT_PUBLIC_ERROR_REPORT_URL, documented in .env.example. This is the one judgement call I would like checked: I defaulted it to https://github.com/Arena1X/InsightArena/issues/new, this project's own tracker. That is right for this repository, but a fork or a white-label deployment would want its own destination — hence the env var. If you would rather the action be hidden entirely when nothing is configured, that is a small change.

Tests

route-error-state.test.tsx grows from 1 case to 18: 4 on isNotFoundError (including the substring trap), 4 on buildReportBody, 4 on buildReportUrl (tracker, mailto, existing query string, absent digest), and 4 rendering cases covering the report link's href and rel, the no-digest path, the 404 screen replacing the crash message, and the absence of a console error for a missing page.

Honest note on verification: I could not run the frontend Vitest suite locally (no full workspace install). All changed files were parsed with the TypeScript compiler API, and the three exported helpers were transpiled and executed standalone against 24 assertions — all passed. One of those assertions checks that the report body is genuinely multi-line, because I hit and fixed an escaping bug there while writing it and wanted a guard against the regression. The four rendering cases need CI.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CrfEY1tvXrbeMDAUzxfuk7

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
insight-arena-4rll	Ready	Preview	Sep 10, 2026 2:10pm UTC