Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetch status code is always 200 except if performing a full page refresh without cache #46621

Closed
1 task done
TCM-dev opened this issue Mar 1, 2023 · 4 comments · Fixed by #47096
Closed
1 task done
Labels
bug Issue was opened via the bug report template.

Comments

@TCM-dev
Copy link

TCM-dev commented Mar 1, 2023

Verify canary release

  • I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 22.2.0: Fri Nov 11 02:06:26 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8112
Binaries:
Node: 18.12.1
npm: 8.19.2
Yarn: N/A
pnpm: N/A
Relevant packages:
next: 13.2.2-canary.1
eslint-config-next: 13.2.1
react: 18.2.0
react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Data fetching (gS(S)P, getInitialProps)

Link to the code that reproduces this issue

https://github.com/TCM-dev/nextjs-error-handling-bug

To Reproduce

  • Starts the project with npm run dev
  • Go to the page http://localhost:3000/
  • Server console logs trueand 200
  • Refresh the page without cache
  • Server console logs falseand 404

Describe the Bug

Using fetch to retrieve data inside a page on server side, the response status code is incorrect when simply loading/reloading the page. It looks like nextjs is caching the response without taking into account the status code.

Expected Behavior

The status code should be corresponding to the status code of the response and not return a 200 by default.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

@TCM-dev TCM-dev added the bug Issue was opened via the bug report template. label Mar 1, 2023
@gernathlub
Copy link

I am experiencing the same bug. The first request performs as expected, but when the response is loaded from cache, the response status code is always 200.

@andrewbateman
Copy link

I can confirm that this is an issue for me also. My application (and probably everyone else's) relies on the status codes being returned as per the original request.

@zek
Copy link
Contributor

zek commented Mar 14, 2023

The problem is here. When we set the cache we don't store the status.

https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/patch-fetch.ts#L189-L206

zek added a commit to zek/next.js that referenced this issue Mar 14, 2023
ijjk added a commit that referenced this issue Mar 14, 2023
Fixes #46621

As explained here #46621,

> Using fetch to retrieve data inside a page on server side, the
response status code is incorrect when simply loading/reloading the
page. It looks like nextjs is caching the response without taking into
account the status code.

In following code we do not add status code information to the cache. 

https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/patch-fetch.ts#L189-L206

However we are accessing this status code in 

https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/patch-fetch.ts#L247-L250

---------

Co-authored-by: JJ Kasper <jj@jjsweb.site>
@github-actions
Copy link
Contributor

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue was opened via the bug report template.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants