Conversation
Next.js throws a set of errors to steer rendering rather than to signal a failure. Its `unstable_rethrow` defines the contract any code wrapping user land in a try/catch has to honor, but the Sentry wrappers only recognized redirects and not-founds. Everything else - most visibly the `HANGING_PROMISE_REJECTION` that Cache Components produces for uncached `fetch()` during a prerender - was reported as an error. Filtering was also coupled to `getActiveSpan()` being truthy, so with no active span nothing was filtered at all, including redirects and not-founds. Fixes #23592 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
size-limit report 📦
|
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
The hanging-promise e2e test concluded "no error was captured" after a fixed 5s sleep, which is flake-prone in both directions: a late event could be missed, and every run paid the full 5s. It now requests a route that captures an error tagged with a token unique to the run. The token guarantees a cache miss, the request happens strictly after the prefetch, and the SDK flushes per request - so once that error arrives, any error the prefetch captured must have arrived too. It doubles as a positive control that errors flow at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
Author
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 223209d. Configure here.
chargome
marked this pull request as ready for review
August 31, 2026 11:43
chargome
requested review from
logaretm,
nicohrubec and
s1gr1d
and removed request for
a team
August 31, 2026 11:43
s1gr1d
approved these changes
Aug 31, 2026
`withServerActionInstrumentation` catches user land errors like the other wrappers, so it honors the same `unstable_rethrow` contract. Next.js only throws these from a prerender scope and server actions run in a request scope, so this is not reachable today - it is consistency and a guard against Next.js routing them differently later. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
chargome
deleted the
charlygomez/js-3434-nextjs-fetch-rejects-after-prerender-completes-on
branch
August 31, 2026 13:00
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Next.js uses some thrown errors as control flow, not as real failures.
unstable_rethrowlists them, and any code that catches user errors is supposed to ignore them. We only ignored redirects and not-founds, so we reportedHANGING_PROMISE_REJECTION,NEXT_PRERENDER_INTERRUPTED,DYNAMIC_SERVER_USAGEandBAILOUT_TO_CLIENT_SIDE_RENDERINGas errors.This shows up most with Cache Components. An uncached
fetch()during a prerender never actually runs — Next returns a promise that never resolves, then rejects it when the prerender is aborted. React throws that rejection away, but our server component wrapper caught it and sent it to Sentry.There was also a second problem: since #18408 the filtering only ran if there was an active span. Without one, nothing was filtered, so even plain
redirect()andnotFound()got reported. Both wrappers now filter regardless of whether a span exists.closes #23592