Is there any way to combine stale-while-revalidate with on-demand revalidation?

[fgnass]

As clearly stated in the docs, calling revalidateTag() immediately purges the cache instead of just marking the entries as stale.

Unfortunately this does not match my use-case which I think is be pretty common:

I have ISR pages that should be cached indefinitely until a webhook gets called by the CMS. Visitors should not have to wait for the fresh content to get rendered but see a stale version while the page is updated in the background.

Is there any way to keep the STALE version around (like with time-based revalidation) when triggering a revalidation via the API?

[kaitk]

We have the same issue and would very much want a solution (stale-if-error as well, in case CMS somehow fails or timeouts).

There is no workaround for keeping the latest stale version AFAIK. Nor can you preventing rendering the page again.

At least there is a workaround to access "some working and cached data" and prevent users from seeing errors or wait too long, but it's hacky, limited and a lot of work:

1. during the build phase process.env.NEXT_PHASE === PHASE_PRODUCTION_BUILD we "route" the CMS fetch requests through a nextjs-better-unstable-cache memoize function with a different tag than the actual fetch requests.
2. During site operations we skip that part and fetch directly from CMS api, with a aggressive AbortSignal.timeout() if there is a timeout or error, we fall back to the memoized function (that at least gives us the working data from build time)

But this "solution" is indeed hackish and limited (doesn't even give the last version, but the one at build). We'd also really like to have an actual stale-while-revalidate solution that works with revalidateTag().

[fgnass]

Interesting approach! My current (and even more hackish) workaround is to call staticGenerationAsyncStorage.getStore() after
fetching data from the CMS and remove the tags that were used for that API call. This way, when revalidateTag() is called, only the fetch cache gets purged but not the route cache. I then use a short time-based revalidation so that all pages get revalidated after 60 seconds. The revalidation in the background is fast, as it uses the cached CMS data. The downside is that users have to wait up to a minute after publishing, before they see the new content.

[tinytortoise-dev]

@kaitk @fgnass
I'm having the same problem and it would be very helpful if you provided some sample code that illustrate your workarounds.

[grabmateusz]

Hi all,
bumping up the question - are there any plans to make it possible to trigger on-demand revalidation in a mode in which stale data will be kept in the cache until the fresh data is fetched?