-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
Fully Compatible
-
Storage Execution 2025-08-04
-
200
-
None
-
3
-
TBD
-
None
-
None
-
None
-
None
-
None
-
None
-
None
When finding a bucket to insert a measurement into, we save the catalog era here and pass this into getEligibleBucket. Within our while loop, where we retry upon getting a WriteConflict, we use this same catalog era over and over again. If we tried to reopen a bucket and encounter a catalog era mismatch, we will keep retrying to open this same bucket until our retry attempts are expired (16 by default) and then fall through to allocating a new bucket.
It seems to me that if we could instead get the current catalog era here, so that upon re-entering this loop upon encountering a write conflict we would have refreshed our catalog era, we would fix this behavior. We would also be storing the catalog era that we had before we entered potentiallyReopenBucket, which is where we release the stripe lock. So as far as I can tell, we would not be in danger of missing any direct writes.