fix(web): notify when a new request replaces the pending one in a run#32719

Problem

On web and desktop, a second approval or question in the same run gave no sound, toast or desktop notification. This happens when the second request replaces the first before the client sees the thread go back to working, for example two approvals raised by parallel tool calls. The notification key was only ${runId}:${status} and a notification fires only when that key changes, so the second request matched the first key and the agent sat blocked with only a sidebar badge.

Reproduction: the coordinator's browser test drives the real startThreadNotifications through the shell atom. It moves a thread from pending request request-1 to pending request request-2 of the same kind in the same run. On main it sends one notification instead of two, for both approvals and questions.

Change

The attention key in ThreadNotificationCoordinator.tsx now also carries the id of the request behind the status. The id comes from the existing resolveBackgroundThreadRequest, which the background screen-reader announcer already uses for the same comparison. A thread's own approval or question contributes its id. Failed, usage-limit and guest-request statuses take no id, so a pending auth refresh does not change their key.

With ids in the key, answering the newer of two pending requests would bring the older one back and announce it again. The notification gate (ThreadNotificationCoordinator.logic.ts) therefore remembers the request keys a thread has shown since it last stopped needing attention, and notifies each one once. The memory clears when the thread goes back to working or settles.

A subagent's request reaches the parent with no id, so it keeps the previous rule: it notifies whenever the key changes. A second subagent request after the parent's own request still notifies. The cost is that a subagent request that becomes the pending one again after the parent's own request is answered can notify a second time.

Scope and approval

Fixes pingdotgg/t3code#32711

Verification

Results on head ce7b5659a3 (main merged in):

• apps/web: vp test run --project browser src/components/ThreadNotificationCoordinator.badge.browser.test.ts: 9 pass. On test-only commit 7f4311dac3 (main plus the new test), both new cases fail: 2 failed and 7 passed.
• apps/web: vp test run src/components/ThreadNotificationCoordinator.logic.test.ts: 6 pass. Its gate case now covers request A, then B, then A again (two notifications; three before the gate change), and own question, then id-less subagent approval, then the question again, then a second id-less subagent approval (it notifies; it was silent before the subagent rule).
• vp run check:changed: format, lint, knip, typecheck, tests and react compiler pass.

Transcript excerpt from the original red and green runs:

Evidence

Captured A1 and J: 2 / 19 matrix rows; 2 / 2 required rows complete for #32719. One before/after recording pair covers both rows. Shell-driver harness: the real coordinator and normal app toast renderer receive synthetic shell atoms. This demonstrates client notification behavior, not server-generated concurrency.

The identical script initializes working run R, shows approval A at sequence 00:02, and replaces it with approval B at 00:04, keeping run R and approval status unchanged with no working gap. At 00:05, hover exposes and pauses the toast stack. Measured from the recordings at 30 fps: the working state first shows at video 00:02.07 before / 00:01.87 after, approval A at 00:04.00 / 00:03.83, and approval B at 00:06.03 / 00:05.87. Each toast slides in from the right edge over about half a second (the toast's own entrance transition, unchanged by this PR), so frames during entry show it partly offscreen. The on-screen labels identify each event. Before: one toast. After: two toasts.

Before recording — f12bb6229c: before.mp4

After recording — 12d0972ba0: after.mp4

Environment: T3 Browser panel, Chromium 157 on Linux x86_64; no device emulation; 1280 × 800 CSS viewport; DPR 2; zoom 1; root font 16 px / 100% font scaling; dark theme; scroll (0,0); actual document visible and focused. Date and Date.now frozen at 2026-09-13 07:00:00 UTC; timers/animation clocks continue. Both sides run their own checkout through T3CODE_DEV_SEED=0 vp run dev. The same one-thread synthetic seed, controlled other-thread route, settings and driver are used. In-app notifications enabled; sound and OS notifications disabled. No notification permission grant/stub was needed. Original DPR-2 assets are retained in the source archive; published stills/videos are downsampled to 1280 × 800 with no cropping or compositing.

Settled-frame validation: On each side, take a screenshot, wait 500 ms, then take another; browser-tool overhead adds roughly 0.4 s. ImageMagick absolute-error count is 0 for both full-resolution pairs. Both images, their stability checks, both diff images and the recording filmstrips were opened and inspected before upload. Diff0 is the absolute per-channel difference amplified at threshold 0; DiffT uses 5% of the channel range (12.75 / 255). The difference bounds are x=864, y=155, width=408, height=121 at publication resolution.

What else changed:

• Only the additional toast, its border, dismiss/action controls and shadow differ. Every pixel outside that region is identical; the first toast and harness content match.
• Video lengths differ by about 0.33 seconds from capture-tool overhead (before 8.50 s; after 8.83 s); the scripted input timing is identical.

Drivers and reproducibility:

To rebuild: select dark appearance explicitly (setAppearanceMode('dark')) before running the driver; setTheme('dark') alone keeps system-following appearance.

shell-driver.js

process-evidence.py

validation.json

source-captures-and-drivers.zip

The archive retains the final raw recordings, both original settled pairs and every driver version written during capture. No source or evidence was committed. The after checkout is clean; the temporary before checkout was removed; all four test ports and the owned browser tab were closed.

Unverified: No required capture remains missing. A2, B–I and K–R were not separately captured or independently rerun; their existing test/source classifications remain as stated in the supplied fixture matrix. Native OS banners/badges, audible playback, desktop-native/mobile behavior and actual server concurrency are not established by this pair. Current-head automated tests/base-red execution were outside this evidence-capture brief and are not claimed here.

Not checked:

• Native OS notification presentation and sound in a real desktop client. The tests assert the Notification constructed by the coordinator.
• Two overlapping requests raised by a real provider. The recording drives the shell state directly.
• Mobile push notifications, which come from the server relay rather than this coordinator.

Review: three rounds by two reviewers. Round 1 found the older request being announced again, and round 2 found a second id-less subagent request going silent; both are fixed above. Round 3: no findings.

AI-assisted; verified with the tests and tools listed above.