Summary
A same-entry permission mutation queue in permissionsStore.ts is keyed by board/access ID across session resets (mutationTails deliberately kept in invalidateOperations). If an old-session transport never settles, a replacement session mutating the same entry waits behind that predecessor while holding its own loading token.
Reproduction Steps
- Submit a permission mutation (update/delete/enable/disable) for entry E under session A; hold its transport unresolved.
- Replace the session so the first owner retires.
- Submit a second mutation for entry E under the new session.
- The second intent never transports while the first stays unresolved, with loading stuck true.
Expected Behavior
Explicit recovery policy for a new-session intent blocked behind an unresolved old-session tail: bounded wait with truthful loading, without allowing old and new writes to commit in reverse order.
Actual Behavior
Unbounded wait on the old tail; the new intent holds a loading token indefinitely.
Scope / Impact
Availability only (MEDIUM): no stale cache or error publication (stale owners are suppressed); the new intent runs with new credentials once the old transport settles. Same class as #3362 (comments) with related stalled-column policy #3357. Sibling slices differ: notification and integration designs clear tails on reset instead of keeping them.
Thesis impact
- Maintenance overhead or capture friction impact: minor; adds a known edge to future queue work.
- Review-first trust/safety impact: none; ordering and suppression semantics hold.
Dependencies
Verification Notes
- Affected endpoints or screens: board access and permissions management surfaces
- Logs or screenshots: none
- Repro frequency: deterministic given a hung predecessor transport
Priority label check
Evidence: frontend/taskdeck-web/src/store/permissionsStore.ts lines 140-141 (keep-tails comment), 193-198 (synchronous registration), 201 (predecessor wait).
Summary
A same-entry permission mutation queue in permissionsStore.ts is keyed by board/access ID across session resets (mutationTails deliberately kept in invalidateOperations). If an old-session transport never settles, a replacement session mutating the same entry waits behind that predecessor while holding its own loading token.
Reproduction Steps
Expected Behavior
Explicit recovery policy for a new-session intent blocked behind an unresolved old-session tail: bounded wait with truthful loading, without allowing old and new writes to commit in reverse order.
Actual Behavior
Unbounded wait on the old tail; the new intent holds a loading token indefinitely.
Scope / Impact
Availability only (MEDIUM): no stale cache or error publication (stale owners are suppressed); the new intent runs with new credentials once the old transport settles. Same class as #3362 (comments) with related stalled-column policy #3357. Sibling slices differ: notification and integration designs clear tails on reset instead of keeping them.
Thesis impact
Dependencies
Verification Notes
Priority label check
Evidence: frontend/taskdeck-web/src/store/permissionsStore.ts lines 140-141 (keep-tails comment), 193-198 (synchronous registration), 201 (predecessor wait).