Repository navigation
Python: Fix Purview cache size accounting when replacing entries - #10257
Eduard van Valkenburg (eavanvalkenburg) merged 1 commit into
Conversation
|
/review |
There was a problem hiding this comment.
MAF Automated Review — Iteration 1
Result: No findings
Scope: full PR (1 commit(s)): b2f6cdcc0989
Model: gpt-5.6-sol
Overview
The change removes the replaced mapping before eviction, so its old expiry tuple is treated as stale rather than decrementing the entry twice. Cache operations contain no suspension points, expiry tuples are validated against the live mapping's expiry, and the regression test verifies eviction, accounting consistency, and removal. These guards prevent a publishable Critical, High, or Medium regression in the reviewed change.
Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.
This PR fixes an issue in
InMemoryCacheProviderwhere replacing an existing Purview cache entry with a larger value could cause incorrect cache size accounting and allow the configuredmax_size_byteslimit to be exceeded.The root cause was that
set()subtracted the size of the previous entry without removing its mapping from_cache. Consequently, when_evict_if_needed()ran, the eviction logic could encounter the old mapping and subtract its size again, resulting in an incorrect byte count.Changes made:
_cachebefore triggering eviction. This ensures that any corresponding expiry timestamp encountered in the heap is correctly treated as stale and skipped.test_growing_entry_at_capacity_maintains_size_and_evicts_other_entry, to verify that replacing an entry with a larger value maintains accurate size accounting, evicts other entries when necessary, and correctly resets the tracked size to zero upon removal.This change ensures consistent cache size tracking and prevents the cache from exceeding its configured memory limit due to incorrect accounting.
Closes #8988