fix: bind direct shard cache to siblings - #1543
Conversation
Performance BenchmarksCompared
|
|
@codex Please sync this PR with current The sibling-content fingerprint is the right fix, but Required change:
I prepared this locally on top of current main as commit |
|
Summary
Sync note
Testing
|
|
@codex Please apply the reviewed fix from local commits Review findings fixed:
Focused validation on current |
Summary
Testing
|
Synchronize with main, fail closed on partial shard identities, and prove safe cache hits.
7224887 to
90eda93
Compare
|
Critical review complete at I tightened the family fingerprint so it cannot silently omit malformed shard entries or accept sampled/unknown hash formats. Reusable entries now require a complete non-empty exact-string shard list, unique resolved members, and full Validation: |
|
Addressed the outstanding cache-safety requests from comments 4654494331 and 4655763347 at head Key fixes:
Focused validation after syncing current |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 08413ffd4c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if shard_info is not None: | ||
| # A representative file key alone cannot describe sibling shard | ||
| # membership, target identity, or incomplete-family state. | ||
| version_config["advanced_shard_family"] = shard_info |
There was a problem hiding this comment.
Use only stable shard data in the cache key
When a sibling shard is touched or recreated with identical bytes, advanced_shard_family_cache_fingerprint remains content-stable, but the version context still also contains the full advanced_shard_family object with shard_targets mtime_ns/ctime_ns stats. Because build_cache_version_context() hashes both entries, the new stable fingerprint cannot produce a cache hit for unchanged shard contents; replace the volatile family object in the version context with the stable fingerprint or strip the stat fields.
Useful? React with 👍 / 👎.
Summary
secure:content hashconfig.jsoncannot return stale config-derived checksmainQA improvements
Validation
08413ffd4cce9cfc6c80f9dac3f5b31dc4eae127243 passed, 4 skippedacross the associated advanced-file handler, large-file handler, and cache correctness modulesgit diff --check: clean