Repository navigation
Conversation
Failing test suitesCommit: 93eeba4 | About building and testing Next.js
Expand output● instant insights tab overlay › should wrap the mobile overlay header only when it does not fit
Expand output● instant insights tab overlay › should wrap the mobile overlay header only when it does not fit
Expand output● cache-components › should not have route specific errors ● cache-components › should not warn about potential memory leak for even listeners on AbortSignal ● cache-components › should prerender fully static pages ● cache-components › should prerender static not-found pages ● cache-components › should render not-found with Suspense in layout without connection errors ● cache-components › should apply a not-found status before resuming an empty shell ● cache-components › should prerender pages that render in a microtask ● cache-components › should partially prerender pages that take longer than a task to render ● cache-components › should prerender pages that only use cached fetches ... truncated ...
Expand output● instant insights tab overlay › should wrap the mobile overlay header only when it does not fit |
|
The failing deploy test appears to be caused by missing Vercel credentials in the fork PR environment ( The other reported failures are from The regular build and build-and-deploy checks are passing. Let me know if you'd like me to rerun or adjust anything on my side. |
|
Small update: #99436 enables Cache Components by default for new apps in 16.4. Since this issue happens in the PPR resume path, I think it’s a bit more important now than when I originally opened the PR. |
|
Hi Next.js team! I'd appreciate a maintainer review or some direction on this fix. This issue is affecting our production application. With I've included regression tests covering 404 responses, valid 200 responses, and redirect behavior. I also noticed that Cache Components are now enabled by default in newly created applications (#99436), which makes this issue potentially relevant to more projects. Some CI failures appear unrelated to the changes, including deployment tests failing because Vercel credentials are unavailable. I'm happy to investigate any failures caused by this PR. Could a maintainer take a look and confirm whether the approach of waiting for resumed render metadata on empty PPR shells is acceptable? If there's a better approach, I'd be happy to adapt the implementation. Thanks! |
What?
notFound()returning HTTP 200 when it is discovered while resuming an empty PPR shell.Why?
An empty prerendered shell could be sent before the resumed render completed. This committed the response headers with a 200 status even though the RSC payload correctly contained a 404 access fallback.
The approach in #95561 propagated every status from the resumed render, which caused the existing redirect tests to fail.
How?
For an empty shell, the runtime now waits for the resumed render metadata before sending the response headers.
Only HTTP access fallback statuses (
401,403, and404) are applied to the document response. For all other cases, including redirects, the original status andLocationheader are preserved.The tests cover the first and repeated 404 responses, a valid 200 response, redirect behavior, Webpack, Turbopack, experimental Turbopack, and a deploy-compatible end-to-end scenario.
Related to #98518
Related to #95561