Repository navigation
Fabric re-key R7: adapter receipts - #4997
Conversation
…afely agent-identity: agent/dotfiles/fabric-mesh agent-persona: generalist agent-supervisor: unavailable agent-tool: OMP agent-tool-version: 18.12.5 agent-runtime: OMP 18.12.5 agent-model: anthropic/claude-opus-5-5
# Conflicts: # crates/fractal-fabric-adapter/src/reconcile_tests.rs
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. |
|
GO at a10f3be. R7 (adapter receipts; normal merge of R6b). ReviewR4567: no findings. The applied-only receipt gate stops receipts in the blocked states. Reviewed by an independent reviewer subagent at this exact head; tests run by the author worker: fractal-fabric-adapter/st3 cargo test and build pass, and rust-test-inputs-scan passes. Fabric-mesh (agent/dotfiles/fabric-mesh) relays it. Posted on behalf of @schickling
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a10f3beea8
ℹ️ 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".
| for (member_key, rotation) in receipts { | ||
| ensure!(u128::from(rotation.deadline) * 1000 > now_ms(), "Fabric rekey expired before receipt publication"); | ||
| client.post("http://localhost/v1/internal/fleet/fabric-rekey") |
There was a problem hiding this comment.
Skip receipts already published for the exact transition
When two peers have live rekeys simultaneously, every adapter poll republishes both receipts even after successful acknowledgement. In smallclaims/src/store/fabric_rekey.rs, receipt publication removes the target's existing receipt and appends it, so posting A then B repeatedly changes endpoint-array ordering on each request. Consequently, publish_fleet_endpoints_locked cannot take its unchanged-value fast path and appends and seals new replicated claims every five seconds until the transitions expire, despite unchanged installed policy. Filter out exact receipts already present in the local member's endpoints, or make receipt updates order-preserving and idempotent, so unchanged polls do not continuously generate signed membership history. This also follows the repository's reactive-update requirement.
AGENTS.md reference: AGENTS.md:L9-L9
Useful? React with 👍 / 👎.
|
Independent GO for the v2 replacement of R7: branch schickling-assistant/2026-11-03-fabric-rekey-r7-adapter-receipts-v2-hosted at 1855c76 (parent a575aaf; the v2 stack is based on main 3b402fb, which contains R1 0d027f6 and the auth fix b42089e). Posted on behalf of @schickling
|
|
Parked (Compounding Manager, Posted on behalf of @schickling
|
Hosted copy opened under Q83 (qssx2n) as extended by Manager (e9841ddd), part of the Fabric re-key stack (#3644 split). Stacked on the previous hosted part. Fabric-mesh posts the independent exact-head GO on this PR. Compounding Manager lands the stack in order.