fix(chat): keep transcript following the live tail (scrollHeight-shrink clamp) — launch-to-msg flake [+ investigation diagnostics]

[weishi-imbue]

Summary

Fixes the intermittent launch-to-msg mac-runner flake (~12–25%): the agent's Slack reply (CI MOCK: greetings from the localhost slack mock.) never appeared in the live chat, only after a reload.

Root cause (frontend — proven by instrumentation, server stack fully exonerated):
The agent reads Slack and reports the message correctly every 30s; the server broadcasts and SSE-forwards each report in real time; the client receives and appends them. But ChatPanel virtualizes the transcript and stops following the live tail when its scroll-follow logic latches userScrolledUp = true. Trigger: while pinned to the bottom, async row measurement settles a row shorter than its estimate → scrollHeight shrinks → the browser clamps scrollTop down → that emits a scroll event the naive scrollTop < previousScrollTop check misread as the user scrolling up. Once latched, following never resumes (the viewport never returns to the bottom because new content keeps pushing it down), so new messages render outside the virtualized window and never enter the DOM until a reload re-anchors at the tail. (This is why canned_body_after_reload was always true, and why it never reproduced manually — a real session keeps following the tail.)

✅ The actual fix — review these

• models/scrollFollow.ts — new pure isUserScrollUp({scrollTop, previousScrollTop, scrollHeight, previousScrollHeight}): a downward scrollTop move that coincides with a scrollHeight shrink is a browser clamp, not user intent.
• views/ChatPanel.ts — track previousScrollHeight in lockstep with previousScrollTop at every programmatic scroll site; use isUserScrollUp in handleScrollEvent.
• models/scrollFollow.test.ts — unit tests for the clamp case (+ shrink/grow/down cases).

🟡 Other real fixes found during the hunt (kept; NOT the flake cause)

Legitimate SSE-correctness fixes surfaced while chasing this; the flake persisted after each, so none was the cause. Worth keeping but please sanity-review:

• server.py _get_events — make the tail snapshot self-consistent (offset/len/total from one read): fixes a tail-anchor snapshot race.
• session_watcher.py is_main_session_event — default an unknown session to MAIN instead of dropping it: fixes a main-session-rotation live-filter drop.
• Response.ts / event_queues.py — appendEvents returns a bool; queue replay-on-register.
• StreamingMessage.ts — SSE staleness watchdog (force-reconnect a half-open/zombie stream after 25s) + visibility/focus reconnect. The visibility-reconnect did not fix the flake; the staleness watchdog is a real robustness improvement. Decide whether to keep.

🔴 Diagnostics — TO BE STRIPPED before merge

Pure instrumentation added to capture the failure mechanism; not for production:

• hang_watchdog.py + main.py wiring (faulthandler all-thread dump on :8000 unreachable)
• server.py: [diag-gen] per-event logging, GET /diag/threads, GET /diag/sessions/<agent_id>
• session_watcher.py: [diag-poll] heartbeat/crash logging
• event_queues.py: [diag-sse] broadcast/register logging (+ event_id/session in the broadcast log)
• StreamingMessage.ts: __sseDiag/__sseDiagMeta counters
• ChatPanel.ts: __chatDiag/__chatScrollDiag (incl. a clampsSuppressed counter used to verify the fix)

Verification

In progress: a 12-run launch-to-msg batch against current main + this fix, with __chatScrollDiag giving mechanistic confirmation — the clamp actually occurs (clampsSuppressed > 0) and userScrolledUp never falsely latches (latchedUp = 0) — not just a pass count (the flake is too low-frequency for pass-count alone). Paired diagnostics live in mngr branch wz/diagnose-si-hang-probe.

🤖 Generated with Claude Code