vercel / next.js

The React Framework
https://nextjs.org
MIT License
126.05k stars 26.88k forks source link

Nextjs serving broken page (500) after revalidate instead of cached one #54797

Open gabrielreisn opened 1 year ago

gabrielreisn commented 1 year ago

Verify canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: 1.22.10
      pnpm: 8.6.10
    Relevant Packages:
      next: 13.4.20-canary.12
      eslint-config-next: 13.4.5
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
    Next.js Config:
      output: N/A

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

App Router

Link to the code that reproduces this issue or a replay of the bug

https://github.com/gabrielreisn/prismic-revalidate-poc

To Reproduce

Those steps to reproduce include some changes from a private CMS repo and will impact the description here

  1. Access a valid page in production build (vercel)
  2. Change content from CMS to include something invalid (eg: links with http:// instead of https)
  3. Trigger an API revalidate route (using revalidateTag)
  4. Refresh the browser page for a new version after the cache purge
  5. The production page will display a 500 error page instead of the latest cached version

Describe the Bug

We are encountering a specific use case in which our CMS provider lacks necessary validations, necessitating us to manually implement these checks within our codebase. Our intention is to leverage on-demand Incremental Static Regeneration (ISR) to enhance the speed of content updates. However, the current behavior is problematic: post cache invalidation (whether on Vercel or localhost using next start), the application displays a 500 error page instead of serving the latest successfully built page as expected, as stated in the documentation.

According to the documentation, the anticipated behavior after cache invalidation is that the system should serve the most recent successfully built page, rather than generating a 500 error page. Unfortunately, the current implementation does not adhere to this expectation. If we attempt to return null from a page or throw an error, this also leads to a 500 error, which is perplexing based on the documentation's guidance.

//app/page.tsx

export default async function Home() {
  const page = fetchPageData("homepage");

  const buttonLink = page.data.slices[0]?.primary.buttonLink as any

// assume that only one of those if statements is available
  if(buttonLink.url.includes('http://')){
    //will cause an error
    throw new Error('http:// is not allowed, please use https://')
  }

  if(buttonLink.url.includes('http://')){
    //will cause an error
    console.error('http:// is not allowed, please use https://')
    return null
  }

  return <div> cms data </div>;
}

Expected Behavior

Upon cache invalidation, the system should display the most recent successfully built page in line with the documentation.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

Vercel

GabrielPPavan commented 11 months ago

Got the exact same issue, any updates on this?

agrattan0820 commented 11 months ago

Yep, got the same issue here.

nevace commented 10 months ago

Same issue here, did you resolve this? I noticed in the Vercel logs, the request to the page after revalidate is a 500 error with the cache set to REVALIDATED. The next request is usually fine but sometime it isn't and returns 500 until a fresh deploy.

jdgamble555 commented 9 months ago

I'm getting this in SvelteKit as well.

nevace commented 9 months ago

For me it was because I was ignoring these warnings. Once I fixed all of these, I didn't get any issues.