Stop app route prerenders after caught request access - #96979
Draft
DavidIlie wants to merge 3 commits into
Draft
Conversation
Contributor
Tests PassedCommit: dce1ce2 |
Contributor
Stats from current PR🟢 1 improvement
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
Build Cache
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (8 files)Files with changes:
View diffsapp-route-ex..ntime.dev.jsDiff too large to display app-route-ex..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route.runtime.dev.jsDiff too large to display app-route.ru..time.prod.jsDiff too large to display 📎 Tarball URLCommit: dce1ce2 |
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
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.
What?
Stops the Cache Components prospective render of a
GETRoute Handler as soon asNextRequestornextUrlaccess has already been recorded, even when userland catches the thrown prerender interruption and returns normally.Adds regression coverage for a handler that reads
request.nextUrl.searchinside a broadtry/catch.Why?
Cache Components prospectively executes
GEThandlers during the build to determine whether their result can be prerendered. Request-bound reads interrupt that probe by throwing. If a broad userland catch swallows the interruption, dynamic tracking still records the access, but Next.js currently runs the handler again in the final prerender probe before classifying it as dynamic.That second execution duplicates catch logging and any other work in the caught path. This is especially confusing for OG and API handlers because the expected control-flow interruption looks like a build failure in user logs.
The thrown interruption itself remains intentional. This change only removes the redundant final probe after Next.js already knows the handler accessed the request.
Related context: #74858
How?
After prospective caches settle, the route module checks the dynamic tracking entries produced by the
NextRequestproxy forrequest.*andnextUrl.*access. It treats those entries as authoritative alongside rejected-promise detection and throws the existingDynamicServerErrorbefore entering the final prerender pass.The check is deliberately limited to request-proxy access. Other dynamic tracking recorded while prospective caches are being filled remains eligible for the final prerender pass.
The regression fixture verifies that the caught build-time path runs once instead of twice and that the request-time handler still receives the real query string.
Verification
pnpm --filter=next build__NEXT_EXPERIMENTAL_STRICT_ROUTE_TYPES=true pnpm test-start-turbo test/e2e/app-dir/cache-components/cache-components.routes.test.ts(10/10)IS_WEBPACK_TEST=1 __NEXT_EXPERIMENTAL_STRICT_ROUTE_TYPES=true pnpm test-start-webpack test/e2e/app-dir/cache-components/cache-components.routes.test.ts(10/10)The regression test fails on
canarywith two build-time catch executions and passes with this change with one execution.