Cache: Stale-while-revalidate not fully working as intended by RFC5861

[daan944]

Description

The main benefit of using stale-while-revalidate is that we can issue a cached but stale response while revalidating in the background. This decreases latency at the trade-off of serving potentially outdated data.

Currently, stale-while-revalidate is not implemented this way. Undici cache does not return the cached value during the stale-while-revalidate window immediately, but revalidates synchronously. The only benefit stale-while-revalidate provides at this moment is the reduction in data retrieval and processing when the endpoint replies with a 304 not modified.

Although this is acceptable according to RFC 5861 section 3, it is quite unoptimal and, in my opinion, unexpected behavior.

Reproducible By

I've made a small repo to test this, see test.ts within.

Expected Behavior

Upon requesting a cached yet stale entry within stale-while-revalidate window, Undici should:

• return the cached yet stale entry immediately
• re-validate the stale entry (and update cache accordingly) in the background
  See RFC 5861 section 3

Environment

Node 24.6.0, Undici 7.15.0, OSX (although I don't it matters).

Additional context

I've tried to update the cache interceptor with a bit of code to check whether we're in the stale-while-revalidate window and return the cached result immediately. That seems to work partially: it does return the stale item immediately, it does perform a revalidate request, but it does not update the cache if the server responds with new data. I might continue on this later.

I've filed this as a bug, as, in my opinion, this is unexpected behavior.