ISR fails to serve 404 pages once the page gets deleted if experimental isr memory cache size is set to 0

[pekarja5]

Verify canary release

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

Provide environment information

Operating System: Platform: linux Arch: x64 Version: #1 SMP Thu, 16 Jun 2022 13:32:35 +0000 Binaries: Node: 16.15.0 npm: 8.5.5 Yarn: 1.22.18 pnpm: N/A Relevant packages: next: 12.1.7-canary.45 react: 18.2.0 react-dom: 18.2.0

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

next start

Describe the Bug

Deleted ISR page shows old generated document even though it is already revalidated and should show 404 page. This usually works as expected, but if you disable ISR memory cache (by setting isrMemoryCacheSize: 0) it stops and always return the stale version of the page.

Expected Behavior

Deleted ISR page should return 404 page

Link to reproduction

https://github.com/pekarja5/next-isr-cache

To Reproduce

1. Build and start the production build of provided repo.
2. Navigate to http://localhost:3000/detail/1
3. In public/detail.json file, change the enabled parameter to 0
4. After 5 seconds (revalidation period) refresh the page twice. First refresh should serve you the stale page while revalidating the page on server and the second should return 404 page, but it does not. Any later request will still serve the original stale version of the page never reaching the expected 404 page.

[cosformula]

Same issue on 12.2.0, a workaround to this is to set notFound : false in getStaticProps.

[TomWebbio]

Any idea when this will get fixed?

[mikael-jarvinen]

Same issue on 13.0.3

This makes self hosting isr almost impossible in those cases when we want to remove pages and have shared static cache between instances.

[joshcoggins]

I'm also seeing this issue and it's preventing us from using deploying our current architecture. Has anyone found a workaround? Adding notFound: false in getStaticProps prevents us from using a 404 page.

[mavr1k]

Same issue on 12.2.5 😢

[mavr1k]

I've made a workaround by passing a specific prop in the getStaticProps, and implementing a client-side redirect to the 404 page:

const Page = ({props}) => {
  const router = useRouter();
  useEffect(() => {
    if (props.notFound) {
      router.push('/404');
    }
  }, [notFound, router]);

  if (notFound) {
    return null;
  }
  renderPage(props)
}
export const getStaticPaths: GetStaticPaths = async () => {
  const document = await getDocument()
  if (document) {
    return {props: {...document } }; 
  }
  return {props: {notFound: true}}
}

I know that solution is not ideal, because the page is still in the memory, but redirect is working and as we don't pass other props, the size of next-data will be reduced.

[ci-scott]

Still present on 13.1.6.

• Page generated on build
• DB updated to disable the page
• Revalidation api called
• Stale page still served (despite notFound: true being returned)
• Works if removing isrMemoryCacheSize: 0 from next.config.js (but we need this due to shared mount resources)

[IgorZanellaDev]

We also have this problem in Customerly (next v13.1.2), hope they will fix it.

[cmaerz]

Same issue here. Will this get fixed?

[MartinDavi]

Is this on anyones radar? Deal breaker for self hosting, and we're doing what is recommended in the docs:

You can use a shared network mount in your Kubernetes pods (or similar setup) to reuse the same file-system cache between different containers. By sharing the same mount, the .next folder which contains the next/image cache will also be shared and re-used. To disable in-memory caching, set isrMemoryCacheSize to 0 in your next.config.js file.

[karlmacklin]

I have done a workaround for this issue that might save someone else suffering from this issue: https://stackoverflow.com/questions/75731978/how-can-you-delete-statically-generated-nextjs-files-on-404-and-redirects

TLDR; - this is an implementation of how to delete the statically generated files yourself. The concept is for a single non-shared mount, so more exotic hosting setups might not be helped by this, but maybe.

[royvou]

See also #53671, issue is that the file based cache does not support redirects / not found results.

[tombburnell]

Just discovered this is affecting my site - using Next 3.3.4. Pages that should be hidden/deleted have reappeared.

[karlmacklin]

Does anyone know if this problem persists with NextJS APP router, or only page router?

[bewards]

This is affecting our site - using Next v13.1.6 and page router. When will we receive an update to this issue?

This looks like the PR Draft that might resolve the issue? https://github.com/vercel/next.js/pull/55107

[karlmacklin]

This is affecting our site - using Next v13.1.6 and page router. When will we receive an update to this issue?

This looks like the PR Draft that might resolve the issue? https://github.com/vercel/next.js/pull/55107

I don't think this is prioritized currently by the nextjs team.

I was reached out to by a community rep on discord just around the release of next 13 and we discussed the issue and the team was supposed to take a look at it but no luck so far.

Given that this is such important basic functionality it SHOULD be fixed, but since it's yet not fixed I don't think it'll ever be fixed.

I've tried my best to trigger this error with next 14 using the app router and it seems it's not suffering from the same problem, so that's another reason I don't think it will be fixed - it's already not a problem if you just adapt the new app router approach.

You will probably just have to delete the files manually in the .next-folder.

[ericdrosas87]

Adding that this is also affecting my team and would love for this to be fixed in the near future