#5359 Fix interquery cache concurrency bug #5361
Conversation
| if oldValueOk { | ||
| c.usage -= oldValue.SizeInBytes() | ||
| } | ||
|
|
There was a problem hiding this comment.
It would be better if we tried to lock the action from the caller rather than do this as described here. Although this helps in representing the correct cache size, we'll be unnecessarily adding items to the list.
✅ Deploy Preview for openpolicyagent ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
@ashutosh-narkar I added a test and comment per your request |
|
I switched the fix with a one liner, |
| @@ -138,6 +138,9 @@ func (c *cache) unsafeInsert(k ast.Value, v InterQueryCacheValue) (dropped int) | |||
| } | |||
| } | |||
|
|
|||
| // By deleting the old value, if it exists, we ensure the usage variable stays correct | |||
There was a problem hiding this comment.
Can we also explain the scenario where we need to take this action. For eg, the concurrent request case.
There was a problem hiding this comment.
This fix simply prevents code like this from breaking the internal state of the cache:
cache.Insert(ast.StringTerm("foo6").Value, cacheValue6)
cache.Insert(ast.StringTerm("foo6").Value, cacheValue6)
I don't see the need to document very explicitly who might call cache.Insert in such a way or why they might do it. At least I wouldn't know how to write that documentation. Feel free to update the comment or give me a suggestion on how to write it
|
|
||
| if dropped != 0 { | ||
| t.Fatal("Expected dropped to be zero") | ||
| } |
There was a problem hiding this comment.
Can we add a test case like this to show the concurrent use case.
There was a problem hiding this comment.
I added a unit test with concurrent inserts
|
@asleire can you please squash your commits and sign it as well. |
asleire
force-pushed
the
main
branch
4 times, most recently
from
8db515e
to
9111b65
Compare
Done :) |
Signed-off-by: Aleksander <Alekken@live.no>
ashutosh-narkar
force-pushed
the
main
branch
from
9111b65
to
2553a6c
Compare
This fixes the issue where concurrent requests with identical cache keys cause the interquery cache size
usagecounter to become invalid, as discussed here