Correct the extreme-ttl doc claims about the sharded stores - #322
Merged
Conversation
Four comments said an overflowing ttl stores no deadline "matching the sharded TTL stores". That is false: the sharded stores clamp the configured ttl to `u64::MAX` nanos before computing a deadline, so their `checked_add` is practically unreachable and they stamp a real far-future `Instant` instead of `None`. The two families genuinely diverge, and both sides are already pinned by tests. No behavior change. Whether to reconcile the families is still open in specs/design/0048-ttl-overflow-vs-clamp.md.
…-docs # Conflicts: # specs/design/README.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four comments claimed that an overflowing ttl stores no deadline "matching the sharded TTL stores". That is false today.
The single-owner stores hold the ttl as a raw
Durationand letnow.checked_add(ttl)overflow toNone, which means never-expires. The sharded stores hold it as anAtomicU64of nanos and clamp on the way in (ttl.as_nanos().min(u64::MAX as u128)), sochecked_addis practically unreachable and they stamp a real deadline about 584 years out. Both behaviors are already pinned by tests, including a cross-family one that asserts the split on purpose.compute_expires_atonTtlCacheandLruTtlCache,cache_setonTtlCache, and a test doc comment intests/v3_traits.rs, all of which repeated the claim.Docs only, no behavior change. The record found two of these; a grep for the phrase found four, which is noted in the record. Whether to reconcile the two families is still an open decision there, and deliberately not settled here.