cloudflare/vinext

App Router: `global-error.tsx` receives generic digest message and lacks built-in fallback

Closed

#1,548 opened on May 22, 2026

 (0 comments) (0 reactions) (0 assignees)TypeScript (371 forks)github user discovery
adapter-api-e2ehelp wanted

Repository metrics

Stars
 (8,563 stars)
PR merge metrics
 (Avg merge 1d 1h) (462 merged PRs in 30d)

Description

This issue was created by an agent analysing CI failures from the Next.js Deploy Suite (vinext main vs Next.js v16.2.6, 2026-05-22).

Problem

Two related global-error issues: (1) when a server or client component throws and is caught by global-error.tsx, the error.message passed to the boundary in production is the generic An error occurred in the Server Components render... digest message instead of the actual error message; (2) when global-error.tsx itself throws, Next.js falls back to a built-in last-resort UI (an <h1>). vinext renders nothing — Playwright cannot locate any h1 within the timeout.

Expected: "Global error: client page error"
Received: "Global error: An error occurred in the Server Components render..."
page.waitForSelector('h1') timeout — no built-in fallback UI when global-error.tsx throws

Estimated Impact

~3 test failures across the deploy suite.

Affected Test Suites

  • test/e2e/app-dir/global-error/basic/index.test.ts (2 failures)
  • test/e2e/app-dir/global-error/error-in-global-error/error-in-global-error.test.ts

Recommendation

  1. Reproduce first in vinext's own test suite. Add a client component that throws and a global-error.tsx. Assert the boundary's error.message is the original message in dev and the digest in prod. Then add a global-error.tsx that itself throws and assert the built-in fallback renders.

  2. Forward real messages to the client boundary. Even in production, the client error boundary should receive enough information (digest+message in dev, just digest in prod) — but currently the message text is being stripped where it should be passed.

  3. Implement a last-resort fallback UI. When global-error.tsx itself throws, render Next.js's built-in <h1> fallback so users do not see a blank page.


Part of #1328.

Contributor guide