fix: correct no-store and no-cache behavior for entity cache#8952
fix: correct no-store and no-cache behavior for entity cache#8952
Conversation
✅ Docs preview has no changesThe preview was not built because there were no changes. Build ID: 1a07ddc4aa30f6c8e149384a ✅ AI Style Review — No Changes DetectedNo MDX files were changed in this pull request. Review Log: View detailed log
|
|
Replaces #8951 whose git history I royally messed up |
rohan-b99
left a comment
There was a problem hiding this comment.
Do we have any tests around no-cache? From a quick search most of them seemed to only cover no-store
| CacheControl::new(request.subgraph_request.headers(), None).ok() | ||
| } else { | ||
| None |
There was a problem hiding this comment.
Rather than use an option here, does it make sense to default to CacheControl::no_store? This is only based on other places in the code where that pattern seems to be used (apollo-router/src/plugins/response_cache/plugin.rs), so let me know if I'm missing something here
There was a problem hiding this comment.
Good question! I believe those other places are used for the response cache-control rather than the request - we should default to both cache and store on the request side
|
@rohan-b99 Added tests in 9020cff - good call out! |
Confusingly,
no-storeandno-cachehave different meanings. Per RFC 9111:no-store: allows serving response from cache, but prohibits storing response in cacheno-cache: prohibits serving response from cache, but allows storing response in cache(NB:
no-cacheactually prohibits serving response from cache without revalidation - but the router doesn't distinguish between lookup and revalidation)The entity caching plugin was incorrectly treating
no-storeas both 'no serving response from the cache' and 'no storing response in the cache.'This PR fixes that behavior.
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
A lot of (if not most) features benefit from built-in observability and
debug-level logs. Please read this guidance on metrics best-practices. ↩Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩