Next.js Discord

Discord Forum

Revalidation issues - RSC and router cache

Unanswered
Short mackerel posted this in #help-forum
Open in Discord
Short mackerelOP
Struggling to understand some inconsistent behaviour with caching/revalidating.

I'm fetching some content from a CMS using fetch and tagging for revalidation.

When the CMS updates an api route hander is hit that uses revalidateTag. This usually works for my collections but occasionally I'm finding that I cannot get the content to update, especially for items that are part of root layout, say navigation etc.

All my components are RSC

I was wondering if this was to do with the interaction between the data cache and the client cache held in the router, something I'm misunderstanding. Often only a redeploy on vercel will update these changes.

After reading the docs in detail I thought this might work

revalidateTag(tag);
revalidatePath("/", "layout");

So revalidating the correct tag and also saying revalidate the root path layout file which has everything underneath it - so essentially purge all cache.

But it's not working.

Any insight would be greatly appreciated.

16 Replies

Giant Angora
@Short mackerel after refreshing the page?
Short mackerelOP
Hey! Thanks for responding.

The best way to describe it is inconsistant

I created a little button that did a router.refresh just to see if it was route cache, but this only worked some of the time.

I'm finding it hard to diagnose the problem.
Refreshing the page in the browser and deleting browser cache often had no effect
Giant Angora
Purging the data cache from vercel should update it but understand that might not be the optimal solution
Giant Angora
Tried to reproduce, is the setup fundamentally different? https://codesandbox.io/p/devbox/divine-moon-m2mkzc
Both revalidations update the server count after refreshing the page, but yeah its not deployed on vercel though
Giant Angora
Anyways I also have issue with (permanently) stale data from RSC (edge runtime) in two separate next projects. Only revalidates by manually purging vercel data cache.

Both projects still need these in RootLayout to be usable:
export const dynamic = 'force-dynamic'
export const fetchCache = 'force-no-store'

Which is suboptimal to say the least.
Short mackerelOP
Thanks for this, I'll take a look at what you've done
My usecase which is essentially a statically sourced marketing site from a cms should be using RSC and then only needing revalidating on cms change - where previously I would have triggered a rebuild (say with Gatsby back in the day)

Perhaps this is not the correct use case for this newer system or maybe having it on vercel adds another layer of cache that I need to consider.

And I'd be happy with hitting a route with a webhook that deleted the vercel data cache - but I quite liked the idea of being able to tag parts of the data and have them revalidate only when needed.
Short mackerelOP
currently struggling with getting it to update even when Vercel cache is purged?! - I'm not sure what would cause it to stop going and getting the fetch requests again
Giant Angora
You should at least try to check if the fetchCache = 'force-no-store' or fetchCache = 'only-no-store' has any effect. Latter will throw from any fetch with forced caching.
Also if you use edge runtime I do not think it supports ISR
Short mackerelOP
I don't believe I'm using edge runtime - is that something I need to opt into though?
Giant Angora
Yeah nodejs is the default, so exporting force-no-store/only-no-store in root layout will tell you if the issue is with next cache or upstream
if that setting fixes it then just check if you have set the desired cache configs for your ISR data
not as familiar with ISR mechanics but you might also want to add export const revalidate = 0 for the debug