-
Notifications
You must be signed in to change notification settings - Fork 28.9k
Open
Labels
bugIssue was opened via the bug report template.Issue was opened via the bug report template.
Description
Link to the code that reproduces this issue
https://github.com/tdanecker/404-test
To Reproduce
Use a static route (/
in the linked repo) with const export revalidate = <some number>
which, depending on a fetch request, either returns notFound()
or the actual content.
In the linked repo:
- Start mocked 404 API responses:
docker-compose up response-404
- Start app:
npm run build && npm run start
- Observe responses:
first response: 404 Page, but status code 200 ❌
subsequent responses after revalidation: 404 Page, status code 404 ✅ - Switch mocked API response to 200:
docker-compose up response-200
- Observe responses:
first response: 404 Page, status code 404 (old stale response)
subsequent responses: correct page content, but 404 status code ❌
Current vs. Expected behavior
Current:
- Next.js first returns a 200 status code for a notFound / 404 page.
- The route doesn't recover correctly from a notFound / 404 page. It sends back the correct content but gets stuck at the 404 status code.
Expected:
- The first response returns the correct 404 status code for notFound.
- After the content is available, the route responds with the content and a 200 status code.
Provide environment information
Operating System:
Platform: linux
Arch: x64
Version: #25~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 20 16:09:15 UTC 2
Available memory (MB): 31695
Available CPU cores: 16
Binaries:
Node: 20.11.0
npm: 10.2.4
Yarn: 3.6.1
pnpm: 7.33.5
Relevant Packages:
next: 14.2.0-canary.31 // Latest available version is detected (14.2.0-canary.31).
eslint-config-next: 14.1.3
react: 18.2.0
react-dom: 18.2.0
typescript: 5.4.2
Next.js Config:
output: N/A
Which area(s) are affected? (Select all that apply)
App Router
Which stage(s) are affected? (Select all that apply)
next start (local), Other (Deployed)
Additional context
On our production setup, after some time (sometimes hours), the status code seems to recover to a correct 200 status code. My theory is, that it recovers once the whole route got ejected from the full route cache.
antimonad, felixmusmann, ARochniak, um2115, mirel-v and 6 more
Metadata
Metadata
Assignees
Labels
bugIssue was opened via the bug report template.Issue was opened via the bug report template.