A second open tab misses short runs: no refetch on focus, first poll tick at 15s, no final fetch when the run ends

[mmabrouk]

Found by Mahmoud during 0.106.2 staging QA, root-caused in code. Follow-up to #5589/#5530. Distinct from #5609 (that is about a tab that never regains focus; this one reproduces WITH focus).

Reproduction

1. Open the same session in two tabs.
2. Send a message in tab 1.
3. Switch to tab 2.
4. Tab 2 shows neither the new user message nor the answer, indefinitely. Archiving and unarchiving the session (which remounts the conversation) is currently the only way to make it converge.

Root cause

For an already-mounted session, only two things ever refetch the transcript (web/oss/src/components/AgentChatSlice/hooks/useSessionHydration.ts):

1. Mount. The hydration effect and the SWR revalidation effect are both keyed [sessionId] and documented "Once per mounted session tab." They ran when the tab first opened and never run again. Nothing re-runs adoption on window focus; the "reconcile on focus" from the [fix] Stop agent sessions breaking when open in two places [AGE-4004] #5589 design covers the session LIST (projectSessions.ts), not a mounted transcript.
2. The remote-run poll, only while runningElsewhere is true. And it has two sharp edges:
   • The first fetch is scheduled with timer = setTimeout(poll, delay) where delay starts at REMOTE_RUN_POLL_MS (15s). No immediate tick when the run is first noticed.
   • The effect cleanup cancels the pending timer the moment runningElsewhere flips false. A run that ends before the next tick discards the pending fetch. There is no final catch-up fetch on the running→idle transition.

Play the reproduction through that: if the answer finished before the tab switch, liveness reports nothing running, the poll never arms, and no trigger remains. If the run was still live at the switch, the poll arms at +15s, most answers finish sooner, the flag flips, and the cleanup cancels the first fetch before it ever fired. Either way the tab fetched nothing and stays stale until a remount.

So for short turns (the common case) a second open tab converges NEVER rather than late. The watermark adoption guard itself is correct — this is purely a triggering gap.

Why it was not caught in release QA

The 0.106.2 QA proved adoption on reload (planted stale cache + watermark, recovered correctly) and cross-tab stream survival. It never tested "already-open second tab, short finished turn, focus switch, no interaction", which is this exact path.

Candidate fixes, smallest first

1. Fire the first poll tick immediately when runningElsewhere flips true (call poll() instead of arming the 15s timer first). One line. Covers the switched-while-running case.
2. One final adoption fetch on the running→idle transition (a small effect on the falling edge, since the cleanup cannot await). A few lines. Covers the run-ended-before-the-tick case.
3. Re-run the guarded adoption on window focus for mounted sessions. Broadest coverage (also fixes the run-finished-before-switch case without relying on liveness timing), but adds a full record-log fetch per focus, which is the request-budget question Arda already weighed in this design. His call.

Fixes 1+2 together close the reported reproduction. Fix 3 is the complete answer and interacts with the #5609 decision.

Severity

Not a regression: on 0.106.1 this tab was stuck permanently (broken message-count guard, no strip, no poll). 0.106.2 is strictly better. But multi-tab convergence was the headline of #5589, and the most common interaction (short turns) still does not converge without a remount, so the feature underdelivers its promise until this lands.

[linear-code]

AGE-4046

[mmabrouk]

The backend side, verified against the code

The frontend triggers above are the shallow fix. The reason a second tab cannot simply listen is structural:

• The event flow is a work queue, not a broadcast. Every record goes into one global Redis stream (streams:records); one consumer group reads it, writes Postgres, then ACKs and DELETEs the entries (api/oss/src/tasks/asyncio/sessions/records_worker.py, shared/consumer.py). Entries are destroyed on ingest, so a second listener would race deletions and lose messages. No browser can subscribe to a run it is not driving.
• No SSE fan-out exists in the API (text/event-stream appears nowhere in api/oss/src); the only live stream is the driving browser's own /run response.
• The record-log read is all-or-nothing (get_records has no windowing or count), which is why the frontend polls it so reluctantly (~200KB, backend-slow).

Fix ladder, ascending cost

A. Cheap version-check endpoint (~a day). GET /sessions/{id}/records/count (or last record index): one indexed COUNT on a table the ingest worker already writes. Tabs poll the tiny number while visible, compare to their watermark, and fetch the full log only on growth. Reuses the adoption guard unchanged, dissolves the request-budget objection behind #5609, and closes both this issue's repro and #5609 in one move. Best effort-to-value.

B. Per-session pub/sub + SSE (~a week). PUBLISH each record batch to a per-session channel next to the existing XADD (fire-and-forget, cannot disturb ingest); add GET /sessions/{id}/events as SSE. The subtle part is resume ordering: subscribe first and buffer, backfill from the client's watermark, replay deduped by record index (ingest lags live events by up to ~250ms of batching; naive backfill-then-subscribe drops the gap). Frontend feeds events through adoptServerTranscript unchanged. Remaining cost is operational (long-lived connections through the ingress, closing idle subscriptions). Correct end state; reverses an explicit budget decision, so it pairs with the #5609 ruling.

C. BroadcastChannel (hours, frontend only). Tab 1 posts "session X grew" to sibling tabs, which run the guarded refetch. Fixes the same-browser repro only; safe where the old localStorage channel was not, because it triggers guarded adoption instead of replacing state.

Recommended sequence: A now, B as the deliberate architecture decision later, C optional. A also makes the one-line frontend patches in this issue's description mostly unnecessary rather than merely mitigated.

[mmabrouk]

Triage decision (Mahmoud, 2026-08-01): take the two stopgap one-liners now, and schedule option A (the records-count endpoint) as the next ticket, since it retires both the stopgaps' polling cost and #5609.

Stopgaps are up as PR #5629: the poll's first tick now fires immediately, and a falling-edge effect runs one final guarded fetch when the run ends. This issue stays open to track option A.