Repository navigation
Phase 4: joiner misses an update made without knowing its concurrent add #189
Description
Found by the P4.7 concurrency property. If an author makes an update without knowing about a concurrent add, the new joiner never receives that update's epoch and holds one epoch fewer (pinned by test_open_a_joiner_misses in src/encryption/tests.rs). Decide: refuse the update when the author has not seen the add, or fetch the missing epoch through the lazy history path (P4.6). Also open from the same track: the heads merge for groups above 32 heads is not built, so such a group cannot publish until it sees fewer heads.
Activity
dezren39 commentedon Oct 24, 2026
id train triage (2026-10-24): needs-decision — project owner: refuse update vs lazy-history fetch when an author missed a concurrent add (pinned by test_open_a_joiner_misses).
dezren39 commentedon Oct 29, 2026
🤖 Agent note · done
a3cdf6c9:pkgs/id/src/encryption/tests.rs:2239annotates the pinned test "Open (P4.7), closed by lazy history (P4.6)"; the test itself (test_open_a_joiner_misses_an_update_made_without_knowing_it, :2244) shows the joiner first missing the epoch and a message being withheld, then recovering the epoch via request/answer/open history and ending with the full epoch set. The driver is production code, not test-only:pkgs/id/src/encryption/scheme.rsfetch_history(~:498) runs request_history → ask_member → open_history. No owner decision remains on this half and no refusal gate was added.doc/2026-10-12T14-33-36Z_phase_4_groups_encryption/…md:88-89): publishes naming >32 parents are refused withSchemeError::TooManyParents, and "The merge in the plan (P4.7: merge when the heads would exceed the cap) is not built. A group with more than 32 heads cannot publish until a member sees fewer of them. This is open." No other issue tracks it (id(local_events): a node with 33+ other authors in its store can never write again — record() builds an after frontier over the 32-hash cap #1736, closed, is the distinct local_events after-frontier cap).repo-health:v1:fix:developing-today/code:issue:189, kind small_fix) scoped to the heads merge only, with a first step of pinning merge semantics from the P4.7 plan text. Issue stays open, labelledqueue/queued; it can close when 2979 lands.47 remaining items
dezren39 commentedon Oct 29, 2026
Agent note — verified again this shift; parked on blocker PR #2335 + merge-queue stall #2403
Queue task 2979 resumed by Lane B. PR #2219 at
2c829c5e: Codex summary at this head reports no findings and all 3 review threads are resolved. Independently re-ran the defining tests on the laptop worktree:cargo test --lib encryption::in pkgs/id — 72 passed, 0 failed, 1 ignored, includingtest_a_group_above_32_heads_merges_and_publishes_again.The red checks on the PR (fmt/clippy family) are not from its diff (encryption/ordering.rs, scheme.rs, tests.rs + the P4.7 doc): the fmt-check log itself shows the Magic Nix Cache 418/Twirp throttling infra failure, and the genuine on-main fmt/clippy breakage is what blocker PR #2335 fixes. Lane B requested a
--failedrerun of run 40899467528 (attempt 2 in progress).Resume: #2335 merged + rerun green + #2403 fixed → update/rebase #2219 if needed, enqueue, verify merged, complete task 2979.
dezren39 commentedon Oct 30, 2026
🤖 Agent note · picked up → parked
dezren39 commentedon Oct 30, 2026
Lane A (queue task 2979): verified terminal state fresh — PR #2219 MERGED 2026-10-30T01:00:10Z (merge commit 4a661ac), blocker #2403 CLOSED, main advanced. The P4.7 heads merge landed under a prior shift once the merge-queue stall cleared; this issue closed 2026-10-30T01:00:12Z. Task 2979 completing as already_done; stale queue/status/work labels removed.
🤖 Agent note · picked up → done (already_done)