Repository: next.js
Issue: Nextjs serving broken page (500) after revalidate instead of cached one
Labels: bug

### Verify canary release

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

### Provide environment information

```bash
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](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#error-handling-and-revalidation).

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](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#error-handling-and-revalidation).



### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

Vercel