Error Fallback and Retry (error.tsx)

Hard · Error Handling

In the App Router, an error.tsx file wraps a route segment in a React error boundary. When rendering fails, Next.js shows your error component instead of the segment and passes it { error, retry }. retry() (stable since Next.js 16.3) re-fetches and re-renders the segment; the older reset() only clears the error without re-fetching. It must be a Client Component, and the rest of the page (layouts, navigation) stays on screen.

Error boundaries only catch errors thrown while rendering. Errors in event handlers, effects and async code (like a failed request) never reach them, so you catch those yourself and keep them in state. That is what you build here: the same fallback experience for an async failure.

fetchStats(tab, attempt) in the starter is a fake Server Function. For visitors the first attempt fails with a digest, the id Next.js attaches to server errors; revenue always fails with a normal message; signups works.

- Tabs: <button>Signups</button>, <button>Visitors</button>, <button>Revenue</button>; Signups is open at the start. Opening a tab starts at attempt 1 and loads its stats.

- While loading, show <p className="loading">Loading…</p>. On success show <p className="value">Visitors: 1200</p> (label and value).

- On failure render <ErrorFallback error={error} retry={...} />: a <div role="alert"> with <p>Something went wrong!</p>, <p className="detail"> and a Try again button. The detail is Error ID: <digest> when the error has a digest, otherwise the error message. (In production Next.js already replaces server messages with a generic text; this fake still carries the secret text so you can see why hiding it matters.)

- retry clears the error and loads the same tab again with attempt + 1.

- Ignore responses that arrive after the user switched tabs (a cleanup flag in the effect), so a slow failure never replaces newer content.

- The tab buttons stay visible in every state.