They devs mentioned:
There look to be a mix of a couple different issues here.
The handling of dynamicParams = false
appears to be the default handling coming from Next.js. When running the site locally, outside the scope of Netlify, I am able to reproduce the behaviour of invalidated pages returning 404s. The way to reproduce this locally:
npm run build
+ npm run start
curl -X "POST" http://localhost:3000/api/invalidate-cache
While this may not the expected behaviour, we don’t have much influence over the fix. The best way forward would be to open an issue with Next.js.
As a potential workaround, they could use dynamicParams = true
and return notFound()
when the route is unknown prior to fetching from their API (this assumes that they have a concrete list of all the routes upfront similar to their reproduction repository).
Another potential way forward (depending on their use case) is to override the default revalidate = false
with a concrete time (e.g. 60 seconds). This doesn’t give them the same fine-grained cache control as on-demand revalidation, however it does still prevent their downstream API from receiving no more than one request every X seconds (where X is the value they configure).
The second issue is surrounding all of their routes becoming invalidated when they call their invalidation endpoint, which has to do with how they’ve configured their fetch route. From their code, they are placing a tag on the fetch call in the component. See here:
const resp = await fetch('...', { next: { revalidate: 316857, tags: [ 'cards'] } });
The way that next handles this is by placing the cards
cache tag on the page as well, such that when they then call revalidateTag("cards")
all pages with that cache tag are revalidated. Seeing as all the routes use the same fetch call with the same cache tag, the result is all of their pages are getting invalidated. I don’t believe there is anything for us to fix here, this seems to be just how things work.
The following was something I noticed as well, but I didn’t want to bring that up till we solved the issue, but the devs have also mentioned it, so I’ll quote it below as well:
Finally, a helpful tip. They are calling purgeCache
directly in their code, which isn’t necessary or advised. The next-runtime will make the appropriate purge calls for them based on their revalidatePath
and revalidateTag
calls.