-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
Fully Compatible
-
ALL
-
Storage Execution 2025-03-31
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In the old write path, if we encounter a bucket that we are trying to reopen and find that it is compressed but fail when trying to compress it, we do not increment numBucketsQueried because we do not call into insertWithReopeningContext, which would increment it by calling into
updateBucketFetchAndQueryStats.
In the new path, we increment it in reopenQueriedBucket, which increments the counter before we check if the bucket is compressed or not.
I think that even if the compression were to be successful, the count would still be off by one between the old path and the new path - we'd have incremented the counter twice in the new path (once when finding it uncompressed, once again when finding it compressed) where we'd have only incremented it once in the old path (once when finding it compressed).