Allow Next to Fail a Statically Generated Route and Successfully Build
Unanswered
Giant wood wasp posted this in #help-forum
Giant wood waspOP
Hi there,
I'm working on a project and I am unable to be able to find the answer to this question.
My app is using the Pages router still.
I am trying to take advantage of Next's ability to regenerate pages properly based on error states/non-error states.
I have a page that we'll "press-releases" that is SSG, that I expect to fail during build time (due to a missing env). I expect that once it's deployed, the app would recall that route and build that page anew, or go to
However, what ends up happening, is that I never actually make it to deployment. This is due to the build failing due to the "press-releases" pages that throws a
How can I get Next to continue building the app even with failed paths? It seems like this behavior should be allowed, based on exactly what the documentation says about it.
Any help is great! Thanks!
I'm working on a project and I am unable to be able to find the answer to this question.
My app is using the Pages router still.
I am trying to take advantage of Next's ability to regenerate pages properly based on error states/non-error states.
I have a page that we'll "press-releases" that is SSG, that I expect to fail during build time (due to a missing env). I expect that once it's deployed, the app would recall that route and build that page anew, or go to
500 if the route still fails... You can see my thought process for this [here](https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration#error-handling-and-revalidation) and the image attached. However, what ends up happening, is that I never actually make it to deployment. This is due to the build failing due to the "press-releases" pages that throws a
500 error (as expected during build). How can I get Next to continue building the app even with failed paths? It seems like this behavior should be allowed, based on exactly what the documentation says about it.
Any help is great! Thanks!
8 Replies
Also even with the revalidate option, I feel failing this during build is still the expected behaviour. Afaik the build process will clear any cache, i.e. a deployment won’t inherit the cache of the previous deployment, so the build process needs to ensure all pages don’t error, so that in the duration between the build and the second request, the server has something to serve for that route.
To fix this you just need to catch the error and return a prop set that basically tells the component “we don’t have that yet, render a fallback for now”, and wait for ISR to revalidate the cache. Tldr don’t throw an error, just return an object saying there was an error instead.
Giant wood waspOP
Hmmm. Yeah that's something I've noticed. Unforutunately, I was hoping I could kinda force the behavior of auto-revalidating based on page error.
The issue with setting up ISR is just that it causes infra issues in our pipeline. And I saw this, and it seemed like (based on the docs) that it would work...
I appreciate your explanation! It makes sense... I just don't know exactly why the Next docs express the logic as it does. It's a bit unclear and makes it seem that it's possible to not cache the page by throwing and it will still resolve fine.
The issue with setting up ISR is just that it causes infra issues in our pipeline. And I saw this, and it seemed like (based on the docs) that it would work...
I appreciate your explanation! It makes sense... I just don't know exactly why the Next docs express the logic as it does. It's a bit unclear and makes it seem that it's possible to not cache the page by throwing and it will still resolve fine.
I think what they meant is that, “if your database blows up on a sunny Sunday then don’t worry, your ISR page will remain up (if it was successfully built before), and only updated when the database comes back”. In your case the page was never successfully built before so there is nothing to fallback to because the build doesn’t access the cache of past deployments
Giant wood waspOP
yeah, i guess that makes sense. 😦 Man it would be really helpful otherwise. But I suppose I can live with it!
Thanks for the help! I appreciate it
Thanks for the help! I appreciate it
Giant wood waspOP
One thought did cross my mind @joulev, Next already kinda has this "generate routes automatically if they are missing" using SSG for dynamic static routes in Next.
It's another reason I assumed this would be totally possible as well. Are you familiar with the static/dynamic generation on server. Used for like product pages etc
It's another reason I assumed this would be totally possible as well. Are you familiar with the static/dynamic generation on server. Used for like product pages etc
@Giant wood wasp One thought did cross my mind <@484037068239142956>, Next already kinda has this "generate routes automatically if they are missing" using SSG for dynamic static routes in Next.
It's another reason I assumed this would be totally possible as well. Are you familiar with the static/dynamic generation on server. Used for like product pages etc
yes, it's a pretty common practice for statically rendered dynamic routes with a large number of possible routes.
but it still follows the rule that, either something is built at build time gracefully (i.e. not with any errors), or not built at all. there is still no scenario in that practice where a route that errors during build time is accepted.
you could also use this practice as a workaround for your issue. say you face this problem in
with this workaround then your page will get skipped entirely during build time, overcoming the rule mentioned above, while still remains statically rendered (except for the very first visitor to that page)
but it still follows the rule that, either something is built at build time gracefully (i.e. not with any errors), or not built at all. there is still no scenario in that practice where a route that errors during build time is accepted.
you could also use this practice as a workaround for your issue. say you face this problem in
/test, then you simply make a dynamic route /[foo], return an empty array in getStaticPaths and in getStaticProps, return notFound when foo !== "test" and return the page props when foo === "test".with this workaround then your page will get skipped entirely during build time, overcoming the rule mentioned above, while still remains statically rendered (except for the very first visitor to that page)