plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first)

domain:server#3 · os-steve · session_01ADHkmQJdgarUjPLNgFBY67

Filing gate: ③ open question 1 of the #29503 dev (os-dev-report 6588119628, site 4), ruled by the seat (6588178193): A on PR #29602, and direction B filed here. Filed by domain:server seat 3. ⛔ Not a claim. Suggested-grade: p2 (same defect class as #29362 / #29503: on an outage, a recompute revokes share grants it should keep).

What happens

packages/plugins/plugin-sharing/src/ownership-queue-service.ts catches any member-table read failure during expansion, warns "contributes nobody until it can", and answers [] (isMember answers false). The file header declares that posture: "a failed read of a member table contributes nobody for that specification (fail closed for every admission that reads it)". ADR-0142 itself does not declare it. D2 says "an empty expansion is a fact, not a fault". D5 says a failed read during assignment "leaves the row as it was … and logs at warn".

After PR #29602 (#29503), every other sharing and approvals recipient read refuses on a failed read. The queue expander is the last one that answers "nobody". So a queue sharing recipient (ADR-0142 D7) is still diffed against a set that is missing its members on an outage, through reconcile (revokeRuleGrantsForRetiredRecipients) and through the per-user recompute via isMember, and its grants are revoked. The approver slate (D6) can likewise route to a shrunk set. Source reading, not reproduced through a public door.

Wanted (direction ruled B)

ADR-0142 amendment first (a governed path; its own PR, approved by GOVERNED_APPROVERS before code relies on it). It adds a line to D2 saying the one expander keeps "nobody" as its fail-closed answer for admission consumers (the access path, claim admission and the assignment pool), while the sharing-recipient grant pass (D7) and the approver slate (D6) refuse on a failed read. Use the repo's ADR amendment-note recipe.
Then the code: expandMembers / isMember take the consumer's purpose, or the D6/D7 callers use a refusing variant. The access path, claim admission and the assignment pool keep failing closed, exactly as today. A refused D7 pass keeps the rule's existing grants and warns, the way plugins: sharing expandRole and approvals role-tier recipients read sys_member at a 10,000-row bound and turn a failed read into an empty list, so a large or unreadable membership silently shrinks the set #29362 isolates a rule. A refused D6 slate follows the approvals site's existing failure class from plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503.
Pins: a failed member read keeps queue-recipient grants on reconcile and on the per-user recompute (red on main); the access path still answers no access on the same failure (control); the approver slate refuses instead of shrinking.

Level: the D6/D7 doors narrow (a recompute that used to revoke now refuses), so expect !, Clause-②: no (narrowing) and the full dogfood battery.

Serial: after PR #29602 merges (same files; its holderCheck wrapper is the seam this card changes).

Dedupe: searched ADR-0142 queue outage, contributes nobody until it can; nearest #29503. New.

Links back: #29503, #29602, #29362.

domain:server#3 · os-steve · session_01ADHkmQJdgarUjPLNgFBY67

Filing addendum · #29604 · 2026-11-02T21:06Z

Carried from should-fix 1 of the CONTRACT_REVIEW_TIER record on PR #29602 (#29503, head 38c62472, PASS). This card owns the queue position case:

Before PR fix(plugins)!: team and position recipients reach every holder past 10,000 rows, and a failed holder read refuses instead of answering nobody #29602, a failed sys_user_position read made holdsPosition fall through to holdsRole, and expandPositionUsers fell through to the sys_member.role transition limb. So on that outage a queue position specification contributed the transition-source holders.
After fix(plugins)!: team and position recipients reach every holder past 10,000 rows, and a failed holder read refuses instead of answering nobody #29602, holderCheck and expandSpec answer false and []. That is the service header's declared "nobody", now reached for the first time.
The consequence: the queue's sharing-recipient pass through isMember now revokes on a sys_user_position outage, where main kept the transition-source holders.
Add to Wanted: the D7 refusal covers this case. The queue posture pin in ownership-queue.test.ts seeds one sys_member transition row, so the pin can see the answer on both sides of the change.

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Path: none

Triage: p2 · `domain:server` · `pm:queue` · 2026-11-02T21:56Z

⛔ Not a claim.

Read fresh. On a member-table outage, a queue sharing recipient revokes grants, because the expander answers "nobody". Same class as plugins: sharing expandRole and approvals role-tier recipients read sys_member at a 10,000-row bound and turn a failed read into an empty list, so a large or unreadable membership silently shrinks the set #29362 and plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503. p2, as suggested. ⛔ The card puts an ADR-0142 amendment first. That is governed Tier H text, so its approval is the maintainer's before the code half lands.

Generated by Claude Code

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Measured reading for this card, carried from #29606 (os-dev-report 6591481172, item 2; seat ruling A on its open question 2). Recorded 2026-11-03T00:01Z.

QUEUE_READ_LIMIT (packages/plugins/plugin-sharing/src/ownership-queue-service.ts) drops holders silently. Measured on a real engine (scratch, not committed):

One queue with 10,001 user member rows: expandMembers answers 10,000; the 10,001st user gets isMember false and queuesOf []. No warning.
10,001 authored queues: queuesOf does not list the last one.
queuesNaming misses a queue past 10,000 rows of one kind.

PR #29647 (#29606) completes the business-unit member reads in plugin-sharing and plugin-approvals but leaves this file alone, because this card owns it and the queue posture. Whoever takes this card should cover the queue reads' 10,000 bound in the same change, or split it out with a measured reason.

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Ruling recorded · B · 2026-11-03T03:07Z

Blocked-by: #29738
Unlock-action: dispatch this card's code half when #29738's PR merges

The maintainer picked B at 2026-11-03T03:05Z on the decision card in the project thread "Decide ruling for card plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first) #29604".
Step 1 is the ADR-0142 amendment, filed as sub-issue docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738. D2 separates an empty expansion from a failed read. Admission consumers (access path, claim, assignment pool) still answer "nobody". The D7 grant recompute and the D6 slate refuse. It is Tier H, at the fable tier with effort xhigh, and waits on the maintainer's approval.
Step 2 is this card's code, after docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738 merges:
- A refused D7 pass keeps the rule's existing grants and warns (plugins: sharing expandRole and approvals role-tier recipients read sys_member at a 10,000-row bound and turn a failed read into an empty list, so a large or unreadable membership silently shrinks the set #29362).
- A refused D6 slate follows plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503's approvals failure class.
- It is narrowing (!), with the full dogfood battery.
QUEUE_READ_LIMIT's silent drop past 10,000 rows (6591670782) is the seat's call. It is covered in step 2 if it fits the same diff; otherwise it is split out with the reason recorded here.
pm:queue → pm:blocked.

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Ruling recorded · B (directory outage at an approval node) · 2026-11-03T09:13Z

The maintainer picked B at 2026-11-03T09:11:47Z on the decision card in the project thread "Decide approvals on directory outage". The question came from the contract review of PR docs(adr): ADR-0142 D2 tells an empty queue expansion from a failed member read; the D6 slate and the D7 grant pass refuse a failed read #29865 (6599389641, ③).
Ruling B: when a directory read behind a queue, team or position approver fails, the approval node refuses to open, under every onEmptyApprovers policy alike (admin_rescue, auto_approve, fail, fallback). It is not routed to administrators, not auto-approved, and not opened on a fallback slate.
Retryable: the node fails loudly with its own error class (not NO_APPROVERS, not "expanded to nobody") and names the read that failed. The run can be re-triggered once the directory reads again. A parked or auto-retry state is not part of this ruling; if one is wanted, it gets a separate card.
This replaces step 2's "a refused D6 slate follows plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503's approvals failure class" (ruling 6594432222). The slate decision in openNodeRequest must see the resolver's directoryFailure, and the queue branch's early "expanded to nobody" return must consult it first. The admission consumers (D3/D4/D5) and D7 are unchanged from that ruling.
docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738 / PR docs(adr): ADR-0142 D2 tells an empty queue expansion from a failed member read; the D6 slate and the D7 grant pass refuse a failed read #29865: the D6 note states this target. That replaces must-fix 1's textual fix in review 6599389641.
Paused: the maintainer has paused new server work. This card's code half stays pm:blocked behind docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738 and is not dispatched this shift.

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Carried to the code half · from contract review 6600699486 (PR #29865, round 2, PASS) · 2026-11-03T10:07Z

D2's read list should also name sys_member, which a position specification reads through the ADR-0057 D4 transition limb (expandPositionUsers → expandRoleUsers; holdsPosition → holdsRole). The code half should treat a failed sys_member read as a failed read. It should also decide, and say, whether the activation-ledger read (switchedOff, answered "on" when the read fails) keeps that posture.
Ruling B (6599731698) covers every slate the node resolves, including a fallback policy's declared fallback slate, which openNodeRequest resolves through the same expandApprovers.
Implementation notes from the review: the resolver's try also wraps the cross-org read filter (bounded), so a failure there refuses the node under the same seam. expandApprovers returns a flat string[], so "openNodeRequest sees it" means either the resolver throws or the contract grows a carrier. The queue branch's early return currently runs before the directoryFailure check and must be reordered. QueueExpansionPurpose (access | addressing) is an independent axis; refuse-vs-nobody must not overload it.

Navigation Menu

Repository navigation

plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first) #29604

What happens

Wanted (direction ruled B)

Filing addendum · #29604 · 2026-11-02T21:06Z

Triage: p2 · `domain:server` · `pm:queue` · 2026-11-02T21:56Z

Ruling recorded · B · 2026-11-03T03:07Z

Ruling recorded · B (directory outage at an approval node) · 2026-11-03T09:13Z

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first) #29604

Description

What happens

Wanted (direction ruled B)

Activity

objectstack-fleet commented on Nov 2, 2026

Filing addendum · #29604 · 2026-11-02T21:06Z

objectstack-fleet commented on Nov 2, 2026

Triage: p2 · domain:server · pm:queue · 2026-11-02T21:56Z

objectstack-fleet commented on Nov 3, 2026

objectstack-fleet commented on Nov 3, 2026

Ruling recorded · B · 2026-11-03T03:07Z

objectstack-fleet commented on Nov 3, 2026

Ruling recorded · B (directory outage at an approval node) · 2026-11-03T09:13Z

objectstack-fleet commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Triage: p2 · `domain:server` · `pm:queue` · 2026-11-02T21:56Z