next.js: GetStaticProps returning initial notFound never triggers a rebuild on revalidate with dynamic routes

What version of Next.js are you using?

10.0.5

What version of Node.js are you using?

12.13.0

What browser are you using?

Chrome

What operating system are you using?

Windows

How are you deploying your application?

next start

Describe the Bug

If getStaticProps returns notFound: true in the initial build with a revalidate value, Nextjs never tries to rebuild the page

Expected Behavior

Nextjs should try rebuilding the page instead of assuming permanent 404

To Reproduce

export const getStaticProps = async (props) => {
  try {
    const dictionaries = await apiFetch();
    return {
      props: {
        dictionaries,
      },
      revalidate: 60,
    };
  } catch (error) {
// assume the api fetch fails with the initial build
   return {
      notFound: true,
      props: {
        dictionaries: {},
      },
      revalidate: 60,
    };
  }

// On subsequent re-builds after revalidate has passed and the api returns a ok response, Nextjs never tries to rebuild the page and always returns the 404 page instead

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 22
Comments: 21 (5 by maintainers)

Commits related to this issue

Fix revalidate for initial notFound: true paths (#28097) This fixes revalidation not occurring correctly when `notFound: true` is returned during build, additional tests have been added to ensure thi... — committed to vercel/next.js by ijjk 3 years ago

Most upvoted comments

Same here, when {notFound: true} revalidate doesn’t happen. Is this gonna be fixed soon? It’s pretty big issue. Thanks

+13

jatbone on Feb 24, 2021

I am encountering a similar experience (but somewhat in reverse).

The initial static page with a dynamic route is built successfully. getStaticPaths uses {fallback: 'blocking'} and getStaticProps uses {revalidate: 1}. Then then the page data is removed from the db so getStaticProps returns {notFound: true}. Despite all this, the static page continues to be served.

I confirmed that the data fetching call that should happen in getStaticProps returns no data, so it appears as though getStaticProps isn’t running at all.

bscaspar on Feb 10, 2021

Same here, when a page is 404 it never gets rebuilt.

ramiel on Apr 27, 2021

@la55u I tried testing out your reproduction and tweaked it a bit to make triggering the notFound easier but it doesn’t seem to behave incorrectly, see below screen recording

@ijjk You did not satisfy the condition of the bug because when you ran yarn build the file contained 200. It has to be the first run that returns notFound: true not one later at some point.

la55u on Aug 11, 2021

We’re experiencing this problem as well. It’s a pretty big issue for us if products are being added to our product catalog that had been a 404 before but won’t revalidate. Would appreciate an update as well. (next v11.0.1)

tbgse on Aug 10, 2021

Still reproduce with revalidate: 60, fallback: “blocking” in next 11.1.2

My mistake. Didn’t added revalidate to return with notFound

NikitaMazur on Oct 19, 2021

I created an other reproduction here: https://github.com/la55u/revalidate-test I cannot deploy it to Vercel due to this bug: https://github.com/vercel/next.js/issues/27948, but here is how to test it locally:

clone the repo
npm run build
npm run start
visit: https://localhost:3000/test

The important part is that steps 2 & 4 should happen at a time when the minute is even e.g. 11:32, so the notFound will return true and the first time you open the page will be 404. Try refreshing the page until the minute is odd and you will still see the 404 page.

la55u on Aug 11, 2021

Thanks for the sandbox @janus-reith, I actually forgot to mention that this happens with dynamic routes, I think how static routes work like in your Sandbox should be the way to go. I made a fork of your sandbox here with dynamic routes. Notice that the /intl/docs/intl-page always serves the 404 page even after revalidate time has passed since it errors during build while /us/docs/us-page page works as intended.

alizeait on Feb 3, 2021