fix(response_cache): do not cache data if age header is bigger than TTL#8456
fix(response_cache): do not cache data if age header is bigger than TTL#8456
Conversation
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
✅ Docs preview readyThe preview is ready to be viewed. View the preview File Changes 0 new, 1 changed, 0 removedBuild ID: 13368e9f12af6c523e1b25b3 URL: https://www.apollographql.com/docs/deploy-preview/13368e9f12af6c523e1b25b3 |
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
There was a problem hiding this comment.
I removed this file to only keep one version between response caching and entity caching
|
|
||
| pub(crate) fn elapsed_inner(&self, now: u64) -> u32 { | ||
| (now - self.created) as u32 | ||
| pub(crate) fn elapsed_inner(&self, now: u64) -> i128 { |
There was a problem hiding this comment.
I return i128 to accept negative values. Because if I return 0 in case created is bigger than current_epoch_time it's a bug and we should not use 0 as value for elapsed it would be incorrect.
| // FIXME: should we add support for must-understand? | ||
| // public will be the default case | ||
| !self.no_store | ||
| !self.no_store && self.ttl().map(|ttl| ttl > 0).unwrap_or(true) |
There was a problem hiding this comment.
This is to avoid the case where age header is bigger than max-age because in ttl() if we have both max-age and age set we now do max_age.saturating_sub(*age) which means it will be 0 instead of the previous overflow.
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
2 participants
Given this example of headers
as
Ageis higher thanmax-ageit should not cache the data because it’s already expiredChecklist
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. ↩