On-demand ISR and error handling

[gabrielreisn]

According to the docs

If an error is thrown while attempting to revalidate data, the last successfully generated data will continue to be served from the cache. On the next subsequent request, Next.js will retry revalidating the data.

However, this behavior seems to differ when utilizing the app router. In my project, I retrieve data from a CMS. Given that I need to perform extensive validation on my end, any exceptions I throw result in an HTTP 500 error, rather than serving the latest cached page.

I'm using Prismic CMS, and their recommendation involves setting up revalidation based on the revalidateTag. Understanding how this aspect of the cache operates can be quite confusing. Would encapsulating everything in a try-catch block work? Or does it only applies to the actual fetch request?

[willemliufdmg]

I've just come across the same problem as you.
I can answer the last bit. Encapsulating everything in a try-catch would allow your page to render without the data (assuming your code doesn't crash anywhere else without the data).

I'm quite baffeled by this cache behaviour as well as it differs from how de old SSG in Page Router used to work and even what the documentation is describing. Old SSG behaviour at least would allow the website to continue working even when the backend is offline. But this new behaviour causes the website to break upon cache invalidation when the backend is offline making this app router less stable as the page router.