Different Caching Strategy than stale-while-revalidate for caching with time based revalidate

[BlankParticle]

Goals

1. Allow different caching strategy than stale-while-revaildate for caching fetch requests
2. Never get stale data when freshness of data is neccessary, but tag based revalidation is not an option

Non-Goals

No response

Background

I am using an third party data source that works like this.

1. Get an access_token based on an refresh_token. It is valid for 3600s. So I use {revalidate: 3550} with 50s margin.
2. Now fetch the actual API with access_token as an Auth Header.

Now here is the issue.

Lets say I got a request and cached access_token for 3550s
Now I serve more request with this cached token. Everything works fine if I get requests too frequently and the access_token gets to revalidate within that 50s margin window.

But If I don't get any request during that 50s window, the access_token expires and doesn't get a chance to revaildate. After that 50s, I get a request, I fetch the access_token it returns the now expired token and revalidates it in backgroud.

But the request that I made with the stale access_token fails due to invaild Auth Headers.
Requests made after this failed one are not affected until the token expires again.

To be honest, I would love to have a option for having the benifit of caching and never sending stale data to the client in cost of having longer response times when some data is stale.

This wpuld be particularly useful with ppr where one could ignore longer response times.

See this similar feature request

Proposal

What I have figured out is while we fetch the cache we can check if the cache is stale or not.
We can wait for the revaildation to complete and set that to the cache and return that same data to the client instead of returning the stale data which maybe days old.

Here is a quick diagram I made

One could opt-in to this feature by using some option like {strategy: "no-stale"}.
I also made a quick dirty prototype of this feature in my local next.js repo and I can say its possible. (Works in dev mode only, gets hydration error in PPR in Prod mode)

Thanks

[pkellner]

I think it goes without saying, but it's important that the "SET" no block the return.

[ttsirkia]

Consider also the following scenario: You have a shop and the prices for the products are fetched from an external source. This data can be cached for one hour. Now if 24 hours passes without any traffic, the next customer will see 24 hours old data although the caching time was limited to one hour. That request starts the data fetching but only the second visitor after 24 hours will see the recent data.

This behavior could be avoided with the suggested solution.

[fgschafer]

I think that opting out of stale-while-revalidate is a must have for a lot of new projects that doesn't have high traffic at first. Is there any plan on implementing this?