Review queue refresh residuals: deep-link re-auth, poll restart after recovery, stale indicator (from PR #2208)

[Chris0Jeky]

Residuals from the review of PR #2208 (Review queue refresh, Refs #2194) that are below the merge-blocking bar or beyond its scope. Triaged once at the two-round ceiling; none of these reopens that PR.

Source: Codex round 2 on head 844c1ad5a (2026-08-29T07:40Z), threads on frontend/taskdeck-web/src/composables/useReviewProposals.ts.

1. Re-authorise a deep-linked proposal before restoring it (Codex P1 → MEDIUM here)

The unscoped list endpoint filters an inaccessible proposal out and returns 200, not 403, so the deep-link pin restores the previously loaded object on ID match alone. Result: a proposal the user can no longer access stays on screen with its operations, provenance and action controls until navigation; any action is rejected server-side with 403. No new data reaches the client (the object was loaded while access was valid), so this is stale state, not a leak — but it is exactly the false-state class the PR targets. Fix direction: re-fetch the pinned proposal (getProposal(id)) when it is absent from the list response and drop the pin on 403/404, or treat absence-from-list as revocation for the pin.

2. Restart polling after permission recovery (Codex P2)

After a 403, clearing the scope calls loadProposals() which clears queueAccessRevoked, but nothing restarts the interval — the recovered queue is a point-in-time read until the route is left and re-entered. Fix direction: startQueueRefresh() on a successful load when queueAccessRevoked was set.

3. Mark the queue stale when refreshes fail (Codex P2)

Repeated poll failures only log, leaving "Nothing waiting. Good." on screen with no degraded indicator — the same false negative the PR removes for the happy path. Fix direction: a queueStaleSince flag set after N consecutive failures, cleared on success, rendered in the eyebrow/live region in both skins.

Fixed in the PR's final round (recorded here for the trail)

• saveRevision() did not replace the proposals array, so a poll started just before it passed both stale-response guards and restored the pre-revision summary/operations/latestRevisionId — fixed on the PR (same class as the round-1 HIGH).
• A late 403 from a superseded scope entered the catch without the load-generation check the success path has, so it could clear a freshly loaded queue for another board and stop polling — fixed on the PR.

Related: #2194 (parent), #2205 (apply-rate split), #2202.

[Chris0Jeky]

Codex round 3 on PR #2208 (posted 07:45Z against 3e9f96b23, after the two-round ceiling; triaged once, tracked here):

4. Announce count-neutral queue replacements (P2)

Both live regions derive from the pending count only, so a poll that removes one pending proposal and adds another in the same response changes nothing textually and emits no announcement. Fix direction: derive the announcement from a queue identity/version (e.g. the write/load generation or a hash of pending IDs), not the count.

5. Bound each in-flight queue refresh (P2)

If the poll GET never settles, refreshInFlight stays true and every later tick returns early — the liveness mechanism switches itself off for the rest of the visit. The shared Axios client has no request timeout; the AbortController is only fired on explicit stop. Fix direction: a per-poll deadline (timeout or AbortSignal.timeout on the poll request) treated as a transient failure, sequenced with item 3 so a stalled poll is also visible.

[Chris0Jeky]

Delta review of PR #2208 (fresh-context, head c7556afae) added detail and LOWs to this tracker:

• Item 2 (restart polling after recovery) — copy detail: the revoked-access banner says "…Reload or pick a board you can still reach." Picking a board runs loadProposals via the activeBoardFilter watcher, succeeds, clears queueAccessRevoked — and the poll stays dead for the session (startQueueRefresh is only called from onMounted). Smallest fix: re-arm the poll in loadProposals' success branch when queueAccessRevoked was true, or drop the "pick a board" half of the sentence.
• LOW: badgeSyncArmed is armed by the first assignment of proposals, and loadProposals' catch never assigns — after a failed entry load the first poll success arms the flag and skips refreshWorkloadCounts() (badge lags one interval).
• LOW: api/http.ts:102 logs Network Error: { message: 'canceled' } for every aborted poll (each Review unmount with an open poll emits a failure-looking entry); no cancellation opt-out equivalent to expectedStatuses.
• LOW: the identity-guard comment at useReviewProposals.ts:566–572 says every decision path assigns a new array, but upsertProposal (line ~390) writes in place (index assign / splice / push) and is not named — safe today only because its sole caller is the deep-link path.
• LOW: LegacyReviewView.vue:288 renders the live region unconditionally above the loading branch, so a screen reader hears "0 proposals awaiting review." under the skeleton, then the real count.
• Coverage gaps: no spec pins the badgeSyncArmed first-assignment skip; the board-scope leg of isSupersededRead() is pinned on the 403 path only, not the success path.

[Chris0Jeky]

Codex round 5 on PR #2208 (post-ceiling, triaged once): Announce the polled permission failure (P2). When a visible Paper Review poll gets a 403, the permission panel is inserted without a live-region role or focus move — a screen-reader user hears only the rail change to "0 proposals awaiting review", not that access was revoked and polling stopped. Legacy's panel uses role="status". Fix direction: give the Paper permission message an announced status/alert role or move focus to it (PaperReviewView.vue ~L1877).