[GH-ISSUE #775] Report errors from stale ISR background revalidation via `onRequestError` #169

New issue

Closed

opened 2026-05-06 12:37:50 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:37:50 +02:00

Owner

Originally created by @github-actions[bot] on GitHub (Apr 4, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/775

Next.js Change

Next.js now reports errors that occur during background ISR revalidation of stale App Router pages via routeModule.onRequestError(). Previously, when a stale cached response was returned and the background revalidation threw an error, that error was swallowed silently (only logged internally by the response cache).

Commit: 9cb2048
PR: #92282

What Changed

In packages/next/src/build/templates/app-page.ts, the response generator function body is now wrapped in a try/catch. When previousIncrementalCacheEntry?.isStale is truthy and the render throws, the error is reported via routeModule.onRequestError() before being rethrown. This ensures instrumentation hooks (e.g., Sentry, OpenTelemetry) see the error even though the user already got a stale response.

This mirrors existing behavior in Pages Router (pages-handler.ts) and Route Handlers (app-route.ts).

Impact on vinext

vinext has its own ISR implementation in isr-cache.ts and server/ modules. If vinext's ISR serves a stale response while triggering background revalidation, errors during that revalidation should also be surfaced — not silently swallowed. This is important for:

Observability: Users relying on error reporting (instrumentation hooks, monitoring) need to see revalidation failures
Debugging: Silent revalidation errors make it very hard to diagnose why pages aren't updating

Suggested Action

Audit vinext's ISR revalidation code paths to check whether background revalidation errors are properly reported or silently caught
If errors are swallowed, add error reporting consistent with Next.js behavior
Ensure any error hooks or instrumentation integrations can observe these failures

Originally created by @github-actions[bot] on GitHub (Apr 4, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/775 ## Next.js Change Next.js now reports errors that occur during background ISR revalidation of stale App Router pages via `routeModule.onRequestError()`. Previously, when a stale cached response was returned and the background revalidation threw an error, that error was swallowed silently (only logged internally by the response cache). **Commit:** [`9cb2048`](https://github.com/vercel/next.js/commit/9cb2048439b8b95b6e6460d17d94d9cb1823fbef) **PR:** [#92282](https://github.com/vercel/next.js/pull/92282) ## What Changed In `packages/next/src/build/templates/app-page.ts`, the response generator function body is now wrapped in a `try/catch`. When `previousIncrementalCacheEntry?.isStale` is truthy and the render throws, the error is reported via `routeModule.onRequestError()` before being rethrown. This ensures instrumentation hooks (e.g., Sentry, OpenTelemetry) see the error even though the user already got a stale response. This mirrors existing behavior in Pages Router (`pages-handler.ts`) and Route Handlers (`app-route.ts`). ## Impact on vinext vinext has its own ISR implementation in `isr-cache.ts` and `server/` modules. If vinext's ISR serves a stale response while triggering background revalidation, errors during that revalidation should also be surfaced — not silently swallowed. This is important for: 1. **Observability**: Users relying on error reporting (instrumentation hooks, monitoring) need to see revalidation failures 2. **Debugging**: Silent revalidation errors make it very hard to diagnose why pages aren't updating ## Suggested Action - Audit vinext's ISR revalidation code paths to check whether background revalidation errors are properly reported or silently caught - If errors are swallowed, add error reporting consistent with Next.js behavior - Ensure any error hooks or instrumentation integrations can observe these failures