ISR caches 404 result, but not status code

[perevernihata]

Verify canary release

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

Provide environment information

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:54 PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64
Binaries:
  Node: 16.18.1
  npm: 8.19.2
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 13.0.7-canary.1
  eslint-config-next: 13.0.6
  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), Middleware / Edge (API routes, runtime), Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue

https://github.com/perevernihata/nextjs-isr-404-caching

To Reproduce

1. clone the repo https://github.com/perevernihata/nextjs-isr-404-caching
2. yarn && yarn build && yarn start
3. Open the browser, open the development console network tab
4. Navigate to http://localhost:3000/articles/test-404-then-200-page-result
5. Observe that the first-time request returns 404, and the second and all subsequent page refreshes return the same Not Found page with a 200 status code. Also, subsequent requests have x-nextjs-cache: HIT header.

Describe the Bug

With ISR enabled, nextjs caches the 404-page content, but it does not cache the status code, therefore 404 is only returned the first time, and the rest of the time it is 200.
I would think, that 400 to 500 status codes should not be cached on ISR at all.
What makes it worse is that I can not conditionally disable caching or ISR for specific results in runtime.

Expected Behavior

I would expect 1 ouf these 2 options:

• All status codes above 400 are not cached by ISR at all
• If the response is cached then the status code is also preserved

Alternatively, it would be also great to have API to decide if we want this specific response to be cached or not, e.g.:

const Article = ({ params }: Props) => {
  const { slug } = params;

  if (slug !== "works") {
    // currently notFound does not support any params
    return notFound({ disableIsr: true });
  }
  return <div>Articles page with slug</div>;
};

Which browser are you using? (if relevant)

Chrome, but irrelevant

How are you deploying your application? (if relevant)

AWS, but irrelevant

[pshemek]

I saw it in my app and I looked at how Next.js 13 playground handles things.
When the route like https://app-dir.vercel.app/ssg/751283748274 is hit, notFound() is triggered but the rendered page is returned with status 200. I would expect the non-existing page would come with the status 404.

BTW: The console says there:
Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.

[fab1an]

Will this ever be fixed, this is a pretty bad bug in my opinion. Having a 404 page not return 404.

[Tekutorukushi]

The error is still present in last version (13.4.19)
it turns out that if I allow all pages for indexing in the robots.txt, then if the page is non-existent, it will still be indexed by robots. Because it will be created on the server as html

[gabiinicial]

I currently have the same error, I am using the latest version of next.js and I have integrated i18next when I trace my links the not-found page returns status code 200 and not a 404.

[ijjk]

Hi, this has been updated in v13.4.20-canary.39 of Next.js, please update and give it a try!

[Tekutorukushi]

If you use Suspense, then the status is 200. Therefore, you need to remove the wrapper from the Suspense in layout

[github-actions]

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