New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plugin/cache: fix negative cache masking cases #3744
Conversation
Signed-off-by: Chris O'Haver <cohaver@infoblox.com>
5272a4f
to
ecefcee
Compare
PTAL @gonzalop |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Thanks for the fix.
Signed-off-by: Chris O'Haver <cohaver@infoblox.com>
Codecov Report
@@ Coverage Diff @@
## master #3744 +/- ##
==========================================
+ Coverage 56.41% 56.47% +0.06%
==========================================
Files 220 220
Lines 11159 11163 +4
==========================================
+ Hits 6295 6304 +9
+ Misses 4379 4376 -3
+ Partials 485 483 -2
Continue to review full report at Codecov.
|
@chrisohaver Thank you for the fix! |
* fix negative cache masking cases Signed-off-by: Chris O'Haver <cohaver@infoblox.com> * remove unecessary param Signed-off-by: Chris O'Haver <cohaver@infoblox.com>
Note: This PR fixes a bug that affects the default usage of cache, not just those who enable stale cache retrieval.
1. Why is this pull request needed and what does it do?
This fixes some bugs introduced when the stale cache retrieval feature was added (#3468):
The first issue is fixed by tweaking the logic in getIgnoreTTL.
The other issue is fixed by having prefetch remove cache entries from the negative cache when writing to the positive cache.
The test added in this PR is based on the test in PR #3702 (thanks @huntharo !)
I also successfully tested this change with tests in PR #3702, which could therefore merge if this PR merges.
This PR should supersede #3736
2. Which issues (if any) are related?
Issues:
#3701
#3586
PRs:
#3702
#3736
3. Which documentation changes (if any) need to be made?
none
4. Does this introduce a backward incompatible change or deprecation?
no