fix(web): narrow stale send spinner recovery to composer state

[hhharryyyyy]

Root cause

The stale send-spinner symptom is local to the composer, but the session lifecycle is not.

Today the composer stop/running state is driven by phase === "running", which comes from the thread session state. In stale cases, that session state can remain running after the latest turn is actually done, so the composer keeps showing the stop state and blocks the next send.

However, latestTurn.completedAt is not a safe global replacement for running state. That was the core mistake in #1700: assistant completion can happen before the turn is fully settled. #1704 reverted that broader semantic change because it overcompensated for legitimate running cases. The earlier discussion in #1393 also correctly identified that follow-up sends and delayed turn-start windows must not clear busy state early.

Why #1700 regressed behavior

#1700 changed shared running semantics by treating a completed latestTurn as no longer running, and then reused that across the composer spinner/stop button, footer layout, auto-scroll, and timer behavior.

That was too broad. It made the composer stop showing running state as soon as latestTurn.completedAt existed, including cases where assistant output had finished but the turn itself was still legitimately running.

Why this fix is narrower and safer

This change leaves shared session semantics alone:

• no change to derivePhase
• no change to isLatestTurnSettled
• no change to broader Working / running indicators outside the composer

Instead, it narrows the stale-spinner recovery to the composer primary action only. The composer now stops showing the running/stop state only when:

• the session still says running, and
• the latest turn has completed, and
• that same turn already has a finalized checkpoint / turn-diff summary

That final checkpoint is a stronger proof of true turn settlement than latestTurn.completedAt alone, because it occurs downstream of full turn completion. This preserves the legitimate-running case that #1700 broke while still recovering the stale composer state when the session lags behind.

Exact verification performed

• bun fmt
• bun lint
• bun typecheck
• bun run --cwd apps/web test src/components/ChatView.logic.test.ts
• bun run --cwd apps/web test src/session-logic.test.ts
• bun run --cwd apps/web test:browser src/components/ChatView.browser.tsx

Regression scenarios covered

• stale spinner after a completed turn:
  • browser test covers a running session whose latest turn already has a finalized checkpoint; composer returns to send state instead of staying on stop
• legitimately running session must still show running state:
  • browser test covers a running session with assistant completion but without a finalized checkpoint; composer still shows stop/running
• follow-up send must not prematurely clear busy state:
  • browser test covers a completed prior turn followed by a delayed thread.turn.start; composer stays in Sending
• long pre-send / delayed turn-start behavior:
  • covered by the delayed thread.turn.start browser case and existing local-dispatch logic tests

Note

Fix stale send spinner by narrowing composer running state to session phase and checkpoint presence

• Adds shouldShowComposerRunningState in ChatView.logic.ts to determine composer running state based on session phase, latest turn completion, and presence of a finalized checkpoint summary for that turn.
• Updates ChatView.tsx to use this function so the Stop button is only shown while the session is running and the latest turn either has no completedAt or lacks a finalized checkpoint; otherwise the Send button is restored.
• Behavioral Change: previously the composer stayed in running/stop state as long as phase === "running"; now it reverts to idle/send once a finalized checkpoint exists for the latest turn, even if the session is still running.

^{Macroscope summarized 1228dab.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 2227a7eb-37ce-4424-9de3-1cfd031879a9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Approved

A targeted bug fix that narrows the condition for showing the composer's running/spinner state. The runtime change is a single 17-line pure function; the rest of the diff is comprehensive test coverage. Clear intent, limited scope, and no side effects beyond fixing the stale spinner behavior.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate 1228dab