fix(desktop): persist elapsed-timer across chat navigation

[DavidMetcalfe]

Summary

Fixes #62158 — the "time elapsed" counter on the chat loading/stall indicators resets to ~0s when the user navigates away from and back to the chat view, instead of continuing to count the in-flight turn.

Root cause: ResponseLoadingIndicator and StreamStallIndicator called useElapsedSeconds() with no key. The hook starts from Date.now() whenever no registry key is supplied, so each component remount (chat switch, Settings open/close, etc.) restarted the timer from zero.

Fix: Key both indicators on the running assistant message id (run:${id}) via the existing shared keyed useElapsedSeconds(timerKey) hook. The module-level startedAtByKey registry persists the start timestamp across unmount/remount, so the counter continues seamlessly. A new prompt produces a new message id → fresh counter.

runningAssistantMessageIdFromThread requires the last thread message to be an assistant message that is currently running (status.type === 'running'), so no stale timestamp is reused during the pre-append transition (last message = user prompt, or a prior completed turn's assistant message).

activity-timer.ts gets a 1000-entry LRU cap on the registry to bound memory across sessions/runs.

Notes

• Desktop-only, no backend changes.
• useThreadRuntime().runId does not exist in the installed @assistant-ui/react (^0.12.28) — verified against node_modules .d.ts. The running assistant message has a stable id in s.thread.messages from run start through streaming + stall (verified in @assistant-ui/core base-thread-runtime-core.js state getter reading mostRecentAssistantMessage). useAuiState(s => s.message.id) is the established pattern in the codebase.
• Open question: assistant-ui appends the running assistant message as the last message when a turn starts; the status.type === 'running' guard is defensive against any gap where the loading indicator would otherwise key off a stale prior-turn id. If the runtime guarantees the running message is always last+running before loading === 'response', the guard is redundant but harmless.
• Cross-vendor Antigravity review (Gemini 3.5 Flash + GPT-OSS) returned APPROVE-WITH-NITS; the one MAJOR it flagged (stale-timestamp transition) is fixed by the running guard above and locked by a regression test.

Test plan

• apps/desktop/src/components/assistant-ui/thread/status.test.tsx (new, 4 tests): timer persists across remount of the same run (9s → 13s); resets on a new run id; does not reuse a stale timestamp when the last message is a user prompt; does not reuse a stale timestamp when the last message is a completed prior-turn assistant.
• apps/desktop/src/components/chat/activity-timer.test.tsx (+2 tests): key-change reset; navigation away/back persistence.
• vitest 7/7 pass; tsc -p . --noEmit clean on changed files.

[teknium1]

Thanks for tracing the remount behavior and covering both anonymous chat-status timer call sites. The underlying issue remains on current main: ResponseLoadingIndicator and StreamStallIndicator still call useElapsedSeconds without a key at apps/desktop/src/components/assistant-ui/thread/status.tsx:62,150.

Problems

• apps/desktop/src/components/assistant-ui/thread/status.tsx:70 introduces runningAssistantMessageIdFromThread(), which calls useAuiState at line 71 but is not named as a custom hook. Desktop ESLint enables react-hooks/rules-of-hooks as an error at apps/desktop/eslint.config.mjs:99-100, so this should be renamed to useRunningAssistantMessageIdFromThread (or inlined into the component) before merge.

Suggested changes

• Rename the helper as a custom hook and retain the current selector/guard behavior; the existing regression coverage can stay unchanged.

Automated hermes-sweeper review.

[teknium1]

useAuiState is called inside this function (line 71), but this lowercase name is neither a component nor a custom hook. apps/desktop/eslint.config.mjs:99-100 enables react-hooks/rules-of-hooks as an error. Rename this to useRunningAssistantMessageIdFromThread or move the selector into ResponseLoadingIndicator.

[DavidMetcalfe]

Closing as superseded — the fix landed on main through a different implementation of the same approach, and the issue this PR targets (#62158) was closed as fixed on 2026-08-15.

Same fix shape, different key source

This PR keyed useElapsedSeconds on the running assistant message id (run:${id}) so the module-level startedAtByKey registry carries the start timestamp across unmount/remount. Current main does the same thing but keys on the per-session turn clock:

• ResponseLoadingIndicator calls useElapsedSeconds(true, turnTimerKey) with turnTimerKey = turn:${sessionId}:${turnStartedAt} — apps/desktop/src/components/assistant-ui/thread/status.tsx:73, 135-136.
• turnStartedAt is seeded at submit (fix(desktop): arm the turn progress timer at submit instead of waiting for message.start #86923), restored from the gateway's turn_started_at on cold resume (fix(desktop): restore turn-elapsed timer across session switches via gateway turn_started_at (salvage #61518) #87237), and scoped per mounted transcript (Unify the preview rail onto one tab list #72963).
• Navigation no longer restarts the counter; a new prompt re-seeds the clock, so the timer still resets between runs — the exact behavior this PR's tests pinned.

Supersession timeline

• fix(desktop): clear stale compaction status across session switches #64127 (merged 2026-07-14) — independently reimplemented the keying (session + turn start instead of message id) while fixing Desktop can keep showing stale "Summarizing thread" status after compaction resumes #48098's stale compaction label; it did not reference this PR or [Bug]: Desktop chat elapsed-time counter resets to ~1s when navigating away and back #62158.
• Unify the preview rail onto one tab list #72963 (merged 2026-07-27) — scoped the timer key per SessionView so transcript tiles never show the primary chat's clock.
• fix(desktop): arm the turn progress timer at submit instead of waiting for message.start #86923 (merged 2026-08-15) — arms the turn clock at submit instead of waiting for message.start.
• fix(desktop): restore turn-elapsed timer across session switches via gateway turn_started_at (salvage #61518) #87237 (merged 2026-08-15) — the gateway reports turn_started_at (from inflight_turn.started_at), so cold-resume restores the clock instead of resetting it.

The PR now conflicts with main after the status.tsx rework, which is consistent with the approach having been replaced wholesale.

Outstanding review item is moot

The hermes-sweeper keep_open review (@teknium1) asked to rename runningAssistantMessageIdFromThread to a custom hook (use… prefix) to satisfy react-hooks/rules-of-hooks. That helper's message-id approach was replaced by the turn-clock keying on main, so there is nothing left to rename.

What wasn't adopted from this PR

• The 1000-entry LRU cap on startedAtByKey in apps/desktop/src/components/chat/activity-timer.ts. Minor memory-bound hygiene, not part of the reported bug — noting it here in case it's wanted as a follow-up.
• The regression tests this PR added (remount persistence, new-run reset) have equivalent coverage on main: apps/desktop/src/components/assistant-ui/thread/status.test.tsx ("preserves each running session timer while switching between sessions").

Residual edge for anyone picking this up

StreamStallIndicator counts "quiet for Ns" from the last activity: quietSince is component-local state (status.tsx:214) and the timer is keyed on the turn clock only while compacting (status.tsx:239-242). Navigate away and back mid-pure-stall (no tool draft at the tail) and the stall timer re-qualifies after STREAM_STALL_S (2s) and counts from the remount, losing the pre-navigation quiet mark. The pre-first-token "thinking" counter — this issue's primary symptom — is fixed; the stall-phase remount edge is arguably by-design since stall semantics deliberately count from last activity (2f5926ed05), but if it should survive navigation, the fix is to move the quiet mark into session-scoped state the same way turnStartedAt was moved.