[Bug]: V2 keep-alive drops queued/waiting threads while UI still shows working #15289

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @ANSHSINGH050404 for the detailed source walk-through. The predicate difference you found is real, but it's the desktop keep-alive's documented scope rather than the stream the composer reads.

   What keep-alive does

   • RunningThreadKeepAlive is mounted only in the Electron shell (apps/web/src/routes/__root.tsx); web and mobile don't keep background threads subscribed. Its job (docs/internals/connection-runtime.md) is to keep threads whose session is starting or running mounted, so opening one doesn't replay. isRunning in apps/web/src/state/threads.ts is that set: preparing, starting, running.
   • The open thread doesn't depend on it. ChatView mounts the detail atom itself through useThreadProjection, useThreadStatus, and useThreadVisibleTurnItems, so keep-alive releasing a thread doesn't close the stream the composer is reading. Phase and Stop come over the shell stream either way.
   • queued and waiting use different predicates. derivePhase maps queued to connecting and waiting to running, and Stop stays available while an earlier run is still interruptible. waiting is the short post-success state until checkpoint capture commits completed (see [BUG] V2 waiting run keeps showing Agent is working and offers Stop for finished work when checkpoint capture stalls #15124), not a live provider session. threadRunStatusIsActive is the sidebar/archive notion of "not settled", not the keep-alive set.

   A narrower case that could be a bug

   Keep-alive keys off the shell's latest-run status, not activityRunStatus. These differ when a later run is queued while an earlier one is still preparing / starting / running. A desktop that connects in that state won't pre-mount the thread, so its first open loads a snapshot. A thread that was already running stays held until that activity run leaves those statuses.

   What would help

   The report is based on reading isRunning and doesn't yet show the open composer missing events. If you've seen a desktop thread that was actively streaming, with a queued follow-up, stall until a manual refresh, please add:

   • The shell status and activityRunStatus while it was stalled
   • Whether that thread was the open route or only in the background
   • Whether the app had just connected, or the thread had already been running in that session

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026
3. ANSHSINGH050404 commented on Oct 3, 2026

   

   ANSHSINGH050404

   on Oct 3, 2026

   ContributorAuthor

   More actions

   Follow-up from the triage note, verified against upstream/main:

   • Keep-alive scope confirmed: RunningThreadKeepAlive mounts only when isElectron (apps/web/src/routes/__root.tsx), and the open thread mounts its own detail via useThreadProjection, useThreadStatus, and useThreadVisibleTurnItems in ChatView. So the open composer does not depend on keep-alive; this is about background pre-mount on desktop.
   • The narrower case reproduces in logic: keep-alive keys off the shell latest-run status (apps/web/src/state/threads.ts runningThreadIdsAtom), not activityRunStatus. When a follow-up is queued behind an active run, the shell reads queued and the thread is not pre-mounted on a fresh desktop connect, so the first open snapshot-loads.
   • Adjusted fix(web): keep queued threads subscribed #15293 accordingly: queued only, waiting left out since it is the short post-success state until checkpoint capture commits. No live-stall trace available here; the remaining claim is the pre-mount gap above, not the open composer missing events.
4. juliusmarminge commented on Oct 12, 2026

   

   juliusmarminge

   on Oct 12, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Fixed by #15293, merged to main. Desktop keep-alive now treats a queued shell run as active, so a thread with a follow-up queued behind an active run stays pre-mounted when the desktop connects. As agreed above, waiting stays out of the keep-alive set because it's the short post-success state before checkpoint capture commits. If you still see a live stall on the open thread, please open a new issue with the shell status and activityRunStatus.
5. juliusmarminge

   removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Oct 12, 2026
6. juliusmarminge

   closed this as completedon Oct 12, 2026