Repository navigation
Comments: NUM_SHARDS is not hashed; GenSet is per-transaction - #866
Conversation
Two source comments, found false by an earlier audit (archived branch core-trace-milestone-1) and still on main: - NUM_SHARDS claimed to be recorded in the commit hash via compute_patch_digest_v2. No digest or state root references it; deltas are merged canonically, so it only affects load balance. - GenSet claimed O(1) checks via a new generation per transaction. The generation is set to 1 and never advanced, each transaction gets fresh sets, and lookups go through a BTreeMap (O(log n)). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 48 minutes. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf9196cc25
ℹ️ 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".
- NUM_SHARDS also caps the effective worker count, which decides how many per-worker deltas the parallel APIs return and which plan they select. Only the committed result is independent of it. - ActiveFootprints, reserve() and the scheduler spec still described generation-stamped O(1) checks. They now describe per-transaction BTreeMap-backed sets at O(log n) per lookup. Found by review of #866. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 026919e756
ℹ️ 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".
Reservation is O(log n) per resource through BTreeMap-backed sets. Found by review of #866. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Corrects two source comments that an earlier audit (the archived branch
core-trace-milestone-1, preserved in the branch bundle) found false. Both are still onmain, and both were rechecked against current code.parallel/shard.rs. The comment saidNUM_SHARDS"is recorded in the commit hash domain viacompute_patch_digest_v2" and that changing it changes hashes.parallel::merge, warp-core: one canonical delta merge for every build #850), so the shard count only decides how work is partitioned.scheduler.rs.GenSetwas described as O(1), with "a new generation per transaction".ActiveFootprints::new.BTreeMap, which is O(log n).Comments only; no behaviour changes.
🤖 Generated with Claude Code
Summary by CodeRabbit