no, that's how nextjs ensures fast serving as well

A little delay wouldnt hurt as much as visitor coming week after last visit and getting week old data which should be refetched 5 minutes after last request

if you need to provide dynamic data you might also want to use dynamic pages and then maybe not cache with nextjs, instead use cloudflare or directly redis for your db (if you using any DB)

This is api endpoint, client side fetches it separately from main page data. This is why it might be used with big delays in between.
And while fully dynamic data is nice, I want to cache it for short time because it uses external api.

why don't you call the external api directly from your client? Why does your external api does not have any cache? Or it have any?

It needs auth, so credentials are stored on server. Plus it is public data, so everyone gets same response for same request. No point in hitting api multiple times within few minutes
No idea about cache, it is google calendar api.

hmm ok. Can't you handle it with a clientside cache? Like requesting your route handler from the client and the client caches it. Then you revalidate more than 7 days times

Client side cache means every visitor still makes request at least once to get potentially same result. Which is perfect situation for caching on server side for few minutes in case of burst visits.
But then next visitor may come many days later after previous and would get super stale data

yea, you can even put it on revalidation time of 10 minutes, to hold up against small burst and cache it on the clientside to cache on the client for one client. To perfect match

But then how to invalidate server cache after 10 minutes without somebody requesting stale data first?

yo can't. But then you have at least 10 minutes old data. If you want fully dynamic data, then it need to be a fully dynamic route. The caching then need to be handled somewhere else

How would you rate chances of this being implemented after feature request?

I don't think that basic functionality will be changed

Next.js should’ve called it “invalidate” instead of “revalidate” since what it’s doing is marking it as stale, needs to fetched again in next Request instead of actually purging the cache for that next request to get the latest data

Name would be more descriptive at least, imo, unless “invalidate” and “revalidate” mean the same thing

I made feature request for it.
Come read it and share your thoughts if you think it is good

https://github.com/vercel/next.js/discussions/76325

There might be a misconception here, the stale-while-revalidate pattern is for exactly this. If you have an SWR time of 5 minutes, and the data is 4 minutes old, it will show the data while it refetches. If the data was 6 minutes old, it will fetch before showing the data

The scenario of coming back after a week and seeing stale data suggests that either the SWR time is too high or it's not working at all

Word "stale" implies it first serves stale data anyway, no?

yes for a limited time

there's two general timeouts, the TTL, which is the time after fetching that it becomes stale

and the SWR which is the time AFTER it's been stale that it's still ok to serve (while it revalidates)

so if you have a ttl of 5 and an swr of 5, a user might get data at most 10 minutes out of date

requests between minutes 0 and 5 serve from cache without triggering revalidation

requests between minutes 5 and 10 serve from cache while revalidating the cache in the background

requests after minute 10 will only serve after it fetches fresh data