Skip to content

After an update restart, resumed threads sit in "Working" for 9 minutes: provider-turn.start waits behind a retrying thread-title.generate effect #25962

New issue
New issue
Closed
#26272
Closed
After an update restart, resumed threads sit in "Working" for 9 minutes: provider-turn.start waits behind a retrying thread-title.generate effect#25962
#26272

Description

@UkrainianCitizen
UkrainianCitizen
opened on Oct 27, 2026

Alpha tester reporting for duty.

Version

0.1.4-nightly.20261027.3770 (macOS desktop, nightly channel).

Setup

The desktop app self-updated and restarted while four threads had active turns (Claude Agent provider). After the final relaunch, the app tried to resume those threads.

Observed

From the server trace log and the state database:

  • About 12 seconds after the server started, EnvironmentCommands.resumeThreadQueue ran once per thread. Each one dispatched a queued-run.start command. The receipt is accepted with no error, and an Orchestrator.startNextQueuedRun span opens.
  • The thread list and the thread view switch to "Working" with a spinner.
  • For about 15 minutes no provider session exists:
    • In the state database, provider_session_runtime and the provider sessions projection have every row for these threads at stopped.
    • Their last provider turn is cancelled (by the pre-restart reconcile).
    • No new provider event log is written under logs/provider/.
    • There is no agent child process on the machine.
    • Nothing in the server trace, the command receipts or the UI reports an error.
  • A user message typed into one of these threads ("continue where you left off") is shown in the transcript but gets no reply during that time, because the thread believes a run is in progress.
  • Roughly 15 minutes after the relaunch, the threads started working on their own, with no user action.

Expected

queued-run.start should start the provider session promptly, or fail visibly and return the thread to idle. If a start is delayed or queued behind something, the UI should say so instead of showing "Working" with nothing running.

Workaround

Wait. A separate issue covers the update itself killing the in-flight turns and relaunching three times.

Activity

  1. juliusmarminge commented on Oct 27, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 27, 2026 – with GitCafe Production
    Member

    Tried to reproduce this on main at e9236274a3, with the Claude Agent provider and "Continue threads after server update" on (the default):

    1. A thread running a long foreground Bash turn, with a second message queued. Graceful server stop, then restart. The restart continuation started its run within a second. Resuming the queue from the web client (Send now, which sends queued-run.start) started the queued run at once.
    2. The same setup, but the server process was killed with SIGKILL mid-turn and then relaunched. Startup recovery queued one provider-runtime.continue per thread. Both were claimed within about 0.1 s, and their provider-turn.start effects ran within 0.4 s.

    In neither case did a start sit idle.

    The server runs a thread's effects one at a time, in order. So a queued-run.start that is accepted but never spawns an agent usually means its provider-turn.start effect is waiting behind another effect on the same thread. To tell which one held yours, could you share the following?

    • The effect rows for one of the affected threads, from statev2.sqlite in your T3 data folder (userdata). Please send them from a copy, not the live file, and redact paths as needed: 
      select rowid, effect_type, status, attempt_count, created_at, available_at, lease_expires_at, completed_at, substr(last_error, 1, 200)
from orchestration_v2_effect_outbox
where thread_id = '<thread id>'
order by rowid desc limit 20;
      If those rows are already gone, send them after it happens again.
    • From the server trace, the OrchestrationEffectExecutorV2.execute spans, with their effect type and duration, between the relaunch and the moment the threads started (about 15 minutes later).
    • Whether "continue where you left off" was typed by you, or whether it is the "T3 Code restarted and resumed this turn" notice that the server adds after a restart.
    • Roughly how large the affected projects' working trees are, including untracked files.
  2. juliusmarminge
    added
    needs more infoInitial triage showed no bug. Awaiting more info
    on Oct 27, 2026

  3. UkrainianCitizen commented on Oct 27, 2026

    @UkrainianCitizen
    UkrainianCitizen
    on Oct 27, 2026
    Author

    You called it. Effect rows for one of the four threads, UTC, from a copy of statev2.sqlite. The other three match within a second.

    rowid effect_type status attempts created_at available_at completed_at last_error
    7028 thread-title.generate succeeded 5 13:06:16.767 13:18:07.458 13:28:43.801
    7035 provider-runtime.continue succeeded 1 13:13:51.465 13:13:51.465 13:14:02.381
    7039 provider-turn.start cancelled 0 13:14:01.932 13:14:01.932 13:14:46.021 Cancelled because the server shut down before the provider work completed.
    7042 provider-runtime.continue succeeded 1 13:14:45.997 13:14:45.997 13:14:50.210
    7046 provider-turn.start cancelled 0 13:14:50.014 13:14:50.014 13:16:57.427 same
    7050 provider-runtime.continue succeeded 1 13:16:57.407 13:16:57.407 13:17:10.448
    7054 provider-turn.start cancelled 0 13:17:10.241 13:17:10.241 13:18:07.445 same
    7058 provider-runtime.continue succeeded 1 13:18:07.414 13:18:07.414 13:19:35.141
    7062 provider-turn.start succeeded 1 13:19:47.926 13:19:47.926 13:28:47.569

    provider-turn.start (7062) was accepted at 13:19:47 and completed at 13:28:47. The effect ahead of it was thread-title.generate (7028), created with the thread's first message, on its fifth attempt, made available again at 13:18:07 by the restart recovery, and completed at 13:28:43. The same row exists for all four affected threads plus a fifth idle thread. All five completed between 13:28:43.729 and 13:28:43.852, within 120 ms of each other, and the four provider-turn.start rows completed 1.5 to 4 seconds later. Five independent title calls finishing together looks like a shared timeout or a worker pool freeing at once, possibly the mechanism in #16636.

    The server trace for 13:19 to 13:28 has rotated out (10 files of 10 MB cover about 20 minutes at this activity level), so I cannot provide the OrchestrationEffectExecutorV2.execute spans. Tell me what to capture and I will try to reproduce.

    "continue where you left off" was typed by me, after the third "T3 Code restarted and resumed this turn" notice. The notices themselves are the server's. Working trees are about 155 MB each, with no uncommitted or untracked files at the time.

    Correction to my title: the wait was about 9 minutes, not 15.

  4. UkrainianCitizen
    changed the title [-]After an update restart, resumed threads sit in "Working" for 15 minutes: queued-run.start is accepted but no agent process starts and no error is raised[/-] [+]After an update restart, resumed threads sit in "Working" for 9 minutes: provider-turn.start waits behind a retrying thread-title.generate effect[/+] on Oct 27, 2026
  5. juliusmarminge
    removed
    needs more infoInitial triage showed no bug. Awaiting more info
    on Oct 28, 2026
  6. juliusmarminge
    closed this as completedin #26272on Nov 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions