Repository navigation
Phase 4: joiner with missing pre-join control messages stalls silently #187
Description
Application messages wait on the control messages they name. A joiner that is missing pre-join controls keeps those messages held with no signal to the user. Welcomes already need that history. Decide whether to surface a stalled-delivery state and how long to wait before asking a member (P4.6 lazy history is the answer path).
Activity
dezren39 commentedon Oct 24, 2026
id train triage (2026-10-24): needs-decision — project owner: surface a stalled-delivery state for joiners missing pre-join controls (P4.6 lazy history is the answer path).
dezren39 commentedon Oct 29, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 29, 2026
🤖 Agent note · done
Verdict: CONFIRMED — delivery waiting on missing pre-join control messages is invisible at HEAD
a3cdf6c9a35df1ff8b88b7a02d62e5c04ca4c94a. There is no signal to the user or to any caller.Evidence (fresh reads of current main, not the issue text):
pkgs/id/src/encryption/ordering.rs—OrdererState.waiting: BTreeMap<Hash, Vec<Hash>>is private, with no accessor anywhere (only internal uses inqueue()/make_ready).queue()inserts a message there whenever a parent it names is not ready, and it waits indefinitely. The module header says it plainly: "A message is delivered once every message it names is delivered… earlier messages wait in the queue."pkgs/id/src/encryption/scheme.rs—Session's public surface (is_welcomed,epoch*,members,process,request_history, …) has nothing that exposes parent-missing waiting messages.request_history()(P4.6) iteratesSession.heldfor messages missing a group secret. It cannot see orderer-waiting messages at all, so the existing lazy-history answer path has no trigger for the pre-join-control case.Routing: the follow-up packet pins the two decisions the issue leaves open — (1) whether to surface a stalled-delivery state: yes, as a read-only
Session::stalled_delivery()returning each waiting message id with the parent ids it is missing, backed by a small accessor onOrdererState; (2) how long to wait: no timer insideSession(it has no clock — same reasoning as the #186 held bound); the surface is immediate and deterministic, and the caller (CLI / sync loop) polls it and drives the existing welcome/history/re-sync paths. No newReceivedvariant, no delivery-semantics change, no dropping of waiting messages. Enqueued as queue task 2977 (small_fix, deduperepo-health:v1:fix:developing-today/code:issue:187, packetqueue-packets/packet-187-fix.json). This issue stays open and is labelledqueue/queuedfor that task.43 remaining items
dezren39 commentedon Oct 29, 2026
🤖 Agent note · parked 20 min — root cause is #2403, not this diff
repo-worker-code), OpenChamber scheduled lanequeue/2977-187-stalled-delivery) · parked, resume 20 minVerified this shift (not re-done work): the branch still carries the implemention exactly as pinned —
Session::stalled_delivery()→Vec<StalledDelivery>sorted by message id, empty before delivery starts, filtered to still-missing parents, no timer, caller contract documented; the three new tests are present. Nothing on the branch needed changing.Why it cannot land (measured, 19:52–19:56Z):
mainis still frozen at5a34fa70(#2233, 10:57Z). The merge queue accepts entries, builds each merge group successfully, then ejects every one on a ~2.5 min cadence, including with an empty queue —#2216,#2367,#2373all ejected,mainnever moved. That is #2403; the keystone for main's fmt/clippy debt (#2151 / PR #2335) is subject to the same ejection, so #2221's check failures cannot be cleared from this lane. Details posted at #2403 and the addendum.Resume brief: once #2403 is fixed and
mainis fmt/clippy-clean —PUT /pulls/2221/update-branch, wait for green, merge under the standing criteria (targeted tests verified, diff matches intent, no hold). Do not re-enqueue #2335 again: task 3495 owns it, and repeated adds were churn.dezren39 commentedon Oct 29, 2026
🤖 Agent note · parked
5a34fa70(no merge since ci: run nix ci on merge groups (merge-queue pilot step 1) #2233, 10:57Z), and PR id(encryption): surface stalled delivery — Session::stalled_delivery() (#187) #2221 is still OPEN / UNSTABLE at head8883eb46. The stall was proven live this shift (PR mcpx: close #1951 remainder — stale dialect-gap rows + structuredContent warn-only policy doc #2190's queue entry ejected ~2 min after enqueue). No update-branch or re-enqueue attempted — both are futile while the queue ejects entries, and id: rustfmt meta_client.rs + drop expect() in tags parser — unbreak main fmt/clippy (#2151) #2335 stays with task 3495 per the standing note.dezren39 commentedon Oct 29, 2026
🤖 Agent note · parked
dezren39 commentedon Oct 29, 2026
🤖 Agent note · parked again — implementation verified, blocked purely on repo infra (openchamber scheduled lane, 2026-10-29T21:52Z)
Resumed task 2977 from its
awaiting_cicheckpoint and re-verified everything fresh; the blocking condition has not moved.MERGEABLE/UNSTABLEat8883eb46, diff still exactly the four intended files (encryption/{mod,ordering,scheme,tests}.rs).test-shard-0throughtest-shard-3,test-unit,cargo-check,docandcrash-gate-*.cargo-fmt-check→/build/id/src/meta_client.rsonlyrustfmt-check→id/src/meta_client.rs,magic-nix-cache/src/main.rstreefmt-check→magic-nix-cache/*, unprefixedsrc/*clippy-lint→magic-nix-cache/*, unprefixedsrc/*None name a file this PR touches ⇒ all four are id: pkgs/id/src/meta_client.rs is not rustfmt-clean on main — every PR inherits three failing fmt checks #2151.
branch_protection_failure, andmainhas not moved off5a34fa70since 10:57:51Z.UNSTABLEuntil the gate lands.Parked 1 h (
not_before22:41Z) rather than 20 min: both resume conditions are external infra fixes, not a CI wait, so a 20-minute retry would just re-observe the same state. Resume when #2403 stops ejecting and #2151 is fmt/clippy-clean on main; then update-branch #2221, merge on green, complete, strip labels. (Not re-enqueuing keystone #2335 from this task — task 3495 owns it.)dezren39 commentedon Oct 29, 2026
🤖 Agent note · parked
dezren39 commentedon Oct 29, 2026
Agent note — blocked on the repo-wide merge-queue stall (queue task 2977, PR #2221)
The fix for #187 is finished: PR #2221
queue/2977-187-stalled-deliveryat head8883eb46, code + tests verified on a previous shift. It cannot go green because it inheritsmain's red fmt/clippy debt (itscargo-fmt-check,clippy-lint,rustfmt-checkandtreefmt-checkjobs fail on files it does not touch), and that debt is only cleared by PR #2335 — which is itself stuck.6f00e7e0) cannot land → id(encryption): surface stalled delivery — Session::stalled_delivery() (#187) #2221 keeps failing the inherited checks → nothing lands at all, because main's merge queue has ejected every entry since 10:57Z (ci: merge queue ejects every PR — no merge since #2233 (10:57Z), entries dropped 2-6 min into AWAITING_CHECKS #2403).escalated-to-useron the ci: merge queue ejects every PR — no merge since #2233 (10:57Z), entries dropped 2-6 min into AWAITING_CHECKS #2403 owner decision (add the merge-queue identity to main's restrict who can push allow-list, or lift it temporarily). Task 2977 is blocked on the same decision rather than cycling through park/resume with an unchanged gate.8883eb46), wait green, merge, complete 2977.Merge pull request #2221 from developing-today/queue/2977-187-stalled…