feat: support staleMaxAge: -1 to always respond stale value

[yassilah]

🔗 Linked issue

Resolves #856

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codecov]

Codecov Report

Merging #857 (511ad87) into main (686a560) will decrease coverage by 0.25%.
The diff coverage is n/a.

❗ Current head 511ad87 differs from pull request most recent head 258249e. Consider uploading reports for the commit 258249e to get more accurate results

@@            Coverage Diff             @@
##             main     #857      +/-   ##
==========================================
- Coverage   67.34%   67.09%   -0.25%     
==========================================
  Files          58       59       +1     
  Lines        5748     5772      +24     
  Branches      611      612       +1     
==========================================
+ Hits         3871     3873       +2     
- Misses       1869     1891      +22     
  Partials        8        8              

Impacted Files	Coverage Δ
src/presets/index.ts	100.00% <0.00%> (ø)
src/presets/edgio.ts	7.40% <0.00%> (ø)
src/presets/layer0.ts	100.00% <0.00%> (+90.69%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[pi0]

Does it makes sense that we directly use !opts.swr here?

[yassilah]

You mean instead of entry.value && !opts.allowStale?

[pi0]

Yes. I suppose it should be expected behavior of SWR to be nonblocking after maxAge. (To be precise, also before staleMaxAge but it is not implemented yet in handler)

[yassilah]

Well tbh I thought so too, but i'm not knowledgeable enough on SWR expected behaviour to answer that 😅
However, the idea of allowStale is to be used in combination with swr because the browser will always send a request after maxAge is invalid but if allowStale is true then the server may respond with outdated data until the background task is finished; by default, the server should wait for the updated data to be fetched before sending a response. Does that make sense or am I completely wrong?

[pi0]

You are definitely not wrong. We use cache options for both Browser<>Server And Server<>Handler caching strategy. And these utils handle Server<>Handler SWR caching strategy similar to browsers (regardless of HTTP client which could be another API or browser)

---

SWR Cache Timeline: 0....maxAge (A) .... maxAge...staleMaxAge (B) ... after maxAge/staleMaxAge (C)

Stage A: Fresh Cache. Use value without revalidate
Stage B: Stale Cache. Respond and revalidate in background
Stage C: Expired Cache. Block and revalidate

Since we didn't implement staleMaxAge yet, it is either B or C. New allowStale flag is identical to staleMaxAge: Infinity.

How about supporting staleMaxAge: -1 as a way to support without new flag?

[yassilah]

Alright, yes I do see what you mean and it would make sense to use the existing staleMaxAge flag to avoid multiplying the options; i'll update the PR

[pi0]

Thanks!