Repository navigation
Closed
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)effort/sSmall: expected under 2 hours of workSmall: expected under 2 hours of workkind/bugSomething isn't working (prefixed form of the classic bug label)Something isn't working (prefixed form of the classic bug label)meta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitiveImportant and time-sensitivesource/queue-workerFiled or worked by the queue/worker pilotFiled or worked by the queue/worker pilottask/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item
Description
Bug: id-core membership test fails on clean main — Refused placeholder flag mismatch
cargo test -p id-core --lib test_a_sequential_named_create_is_refused_even_with_the_smaller_id fails on clean origin/main (verified 2026-11-03 on 4a3d8a2, laptop; also reproduced on an unrelated merged branch, so it is pre-existing and not caused by that work).
Panic at pkgs/id/crates/id-core/src/membership/layer.rs:1014:
assertion `left == right` failed
left: [(Hash([77, 167, ...]), Refused { reason: Gate(GroupExists), placeholder: true })]
right: [(Hash([77, 167, ...]), Refused { reason: Gate(GroupExists), placeholder: false })]
The sequential named create IS refused with Gate(GroupExists) as the test intends; only the placeholder flag on the refusal differs (actual true, expected false).
Acceptance
- Determine which side is correct: a sequential (non-fold?) named create refused for an existing group — should the refusal be a placeholder or not?
- Fix the layer or the test so the suite is green on main, with the reasoning recorded here.
Found by queue task 6505 (lane code-j) while verifying PR #3998; split out so it is tracked instead of buried in that task's notes.
Acceptance criteria
-
cargo test -p id-core --lib test_a_sequential_named_create_is_refused_even_with_the_smaller_idpasses on clean main. - The Refused placeholder-flag semantics are decided (expected
placeholder: truevsfalse) and the fix lands in the membership layer or the test, whichever is wrong, with the reasoning recorded on this issue. - Full
id-corelib suite green in CI after the change.
Metadata
Metadata
Assignees
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)effort/sSmall: expected under 2 hours of workSmall: expected under 2 hours of workkind/bugSomething isn't working (prefixed form of the classic bug label)Something isn't working (prefixed form of the classic bug label)meta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitiveImportant and time-sensitivesource/queue-workerFiled or worked by the queue/worker pilotFiled or worked by the queue/worker pilottask/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item
Activity
dezren39 commentedon Nov 3, 2026
Intake review
Related: filed by lane-k during task 6505's shift (issue #242 work) after the same failure reproduced on clean main
4a3d8a2d7— it is pre-existing, not a regression from that branch.Notes: the refusal itself works (Gate(GroupExists)); only the
placeholderflag on the Refused outcome mismatches (trueproduced,falseexpected atpkgs/id/crates/id-core/src/membership/layer.rs:1014). Either the sequential-create path should not mark the refusal as a placeholder, or the test's expectation predates the placeholder semantics — the triage should decide which side is authoritative before editing.Risks: low — single test, single crate; but a wrong call here could mask a real placeholder-accounting bug, so the verdict matters more than the edit.
Suggested approach: trace where
Refused.placeholderis set on the sequential named-create path, compare with the concurrent path's semantics, then fix the wrong side.🤖 Agent note · filed
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7443 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 4, 2026
agent-note:v1
state: picked up
Task 7443 (triage) claimed by lane code-c, execution lane direct. Reproducing the named id-core test fresh on current main and reading the membership layer to determine whether the layer or the test is wrong about the Refused placeholder flag.
Found via: repo-queue worker shift lane C 2026-11-03
dezren39 commentedon Nov 4, 2026
agent-note:v1
state: triaged — already fixed on main; closing
Triage of task 7443, fresh verification (2026-11-03 ~19:05 CST):
placeholder: false. That is now the documented contract inMembership::refuse("Gate refusals passstand_in: false…").49bd07f85"fix(id-core): gate refusals never stand a placeholder in the auth graph" (layer.rs only), merged via PR fix(id-core): gate refusals never stand a placeholder (membership test failure on main) #4735 on 2026-11-03T02:27Z.4a3d8a2d7is dated 2026-11-02 20:12 CST — 15 minutes before the fix commit (20:27 CST) and hours before the merge. Confirmed by ancestry:49bd07f85is NOT an ancestor of4a3d8a2d7, and IS in current main.65c7ff64f, clean worktree on the laptop):cargo test -p id-core --lib test_a_sequential_named_create_is_refused_even_with_the_smaller_id— passedcargo test -p id-core --lib(full suite) — 283 passed, 0 failedAll three acceptance criteria are met by PR #4735 plus this verification. Closing as completed.