[Nit]: No "starting agent" state while the provider boots; only "Syncing messages..." shows for ~15s

[josephv123]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Run t3 serve on a Linux host and connect from the macOS desktop app through the relay.
2. Start a new Claude thread and send the first message, on a host where the Claude CLI is slow to boot (in my case the host was heavily loaded).
3. Watch the composer and timeline while the provider session starts.

Expected behavior

While the server is starting the provider session and waiting for the first provider event, the UI shows what it is doing (for example "Starting Claude…"), and the "Working for Xs" row appears as soon as the message is sent.

Actual behavior

For about 15s the composer only shows "Syncing messages...", which describes the client's thread-detail sync state, not the provider. After that, "Working for 16s" appears with the timer already partly elapsed. From the UI you can't tell whether the message was received, whether the connection is broken, or whether the agent is starting up.

Server trace for that turn (thread a81c39ea…, all times UTC):

08:08:44.270  orchestration.command.thread.turn.start        93ms
08:08:44.502  processTurnStartRequested                    1879ms
08:08:45.024  ensureSessionForThread                       1356ms
08:08:45.886  startSession (claudeAgent)                    102ms
08:08:46.415  sendTurn                                    13900ms   <- no user-visible state for this whole span
08:08:47.361  ws.rpc.orchestration.subscribeThread         Interrupted (4.1s)
08:08:51.395  ws.rpc.orchestration.subscribeThread         Interrupted (31.4s)
08:08:59.736  turn.started (first provider event)

Most of the 13.9s sendTurn is Claude CLI boot. On the same host, claude -p took 14.2s to emit system/init even with --strict-mcp-config. That part is environmental. The UI issue is that nothing tells the user this phase is happening, and the working indicator doesn't appear until it ends.

Impact

Nit: minor UX polish. Nothing breaks and no data is lost.

Version or commit

t3 v0.0.42

Environment

Server: Ubuntu, Linux 7.0.0, headless t3 serve (background service), 8 cores and 6.6 GB RAM, heavily loaded (load avg ~100). Client: macOS desktop app over the t3coderelay relay. Provider: Claude Code 2.1.283.

Workaround

None. You just have to wait.

[juliusmarminge]

Triage

This is a real chat-surface bug on v0.0.42, and it is still present on current main (nightly 0.0.43 at d2c9281). The 14s Claude CLI boot is environmental, as you measured. The missing status is not.

The server already marks the session starting before sendTurn (ensureSessionForThread with pendingTurnStart). The sidebar maps that to Connecting. The timeline does not. isWorking in ChatView includes phase === "running" and the local send flag, but the isConnecting it also checks is useState(false) and nothing ever sets it. derivePhase does return "connecting" for a starting session, and that is what keeps the local send busy (hasServerAcknowledgedLocalDispatch), but only on the same mounted view.

That local flag is cleared on purpose when the draft promotes. resolveDraftPromotionNavigationTarget swaps to the thread route as soon as the user message is persisted (thread.turn.start, your 93ms span), and this effect runs because draftId becomes null:

apps/web/src/components/chat/ChatView.tsx (lines 5808–5817):

  useEffect(() => {
    setOptimisticUserMessages((existing) => {
      // ...
      return [];
    });
    resetLocalDispatch();
    setExpandedImage(null);
  }, [draftId, resetLocalDispatch, threadId]);

After that, a starting session is not working. latestTurn is not written until turn.started, and that write stamps startedAt from the pending turn's requestedAt (ProjectionPipeline). So the row shows up only when the provider emits its first event, already reading Working for 16s.

Syncing messages... is a second, overlapping mask. That composer row is the thread-detail sync phase (empty / cached / synchronizing), and it replaces the activity slot for as long as the phase is set. Your two subscribeThread spans are that subscription being interrupted and replaced during sendTurn, which forces synchronizing again. On a host at load ~100, that handshake can cover the whole boot, so the composer describes sync instead of provider startup. There is no "Starting Claude…" string.

Open PR #14000 is the right fix for the dead isConnecting flag: derive it from phase === "connecting", so a reload, the draft-to-thread handoff, or another client still shows the working row while the session is starting. It does not change the sync label, and until latestTurn exists the row's timer has no start time (local dispatch was already reset), so it can still jump to the backdated duration when turn.started lands.

[josephv123]

Still present on main at 8f75697: isConnecting in ChatView.tsx is still useState(false) and its setter is never called, so a starting session isn't shown as working after the draft promotes to the thread route.

The triage above named #14000 as the right fix. It was closed for missing live-client verification, and that evidence was posted on the PR about an hour later. It includes before/after screenshots and recordings of a delayed SessionStart hook, a reload during startup, and a failed startup. @juliusmarminge, could #14000 be reopened for reconsideration? It's a one-file change, and Macroscope approved it.