[Bug]: Grok thread stays running forever after t3_worktree_handoff; later messages stay queued
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
Línea de trabajo
Start in apps/server, especially RunExecutionService.ts around the ingestion-failure handler near line 1734, and trace how a hand-off detach interacts with AcpAdapterV2.interruptTurn and runtimeTransitionPermit. Compare Grok's behavior with the Codex hand-off fix in #24545 and the related approaches in #22971 and #22825. Done means the hand-off run reaches a terminal state and a later message runs in the new worktree.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
[!NOTE]
🤖 Claude Opus 5.5 responding on behalf of leonhoulier
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Fresh T3 home, Grok provider enabled, a git project.
- Start a Grok thread and let one turn finish.
- In the next turn, ask the agent to call
t3_worktree_handoffwith nocontinuationPrompt. - After the tool returns, send another message.
Expected behavior
The hand-off turn ends, as it does for Codex since #24545, and the next message runs in the new worktree.
Actual behavior
The worktree is created and bound to the thread, but the hand-off run never settles. The thread stays running with the hand-off run active, and every later message stays queued. I watched it for 30+ minutes, reproduced on 3 of 3 fresh threads.
The same test with other providers on the same server:
| Provider | Hand-off turn | Next message |
|---|---|---|
| Codex | completed | runs in the worktree |
| Claude | failed: "The provider event stream closed unexpectedly" (#22971) | runs in the worktree |
| Muse | failed: same message | runs in the worktree |
| Grok | stays running forever |
stays queued |
From the server trace, in this order:
mcp.tool.t3_worktree_handoffsucceeds.ProviderSessionManager.detachruns. Inside it,AcpAdapterV2.interruptTurnexitsInterruptedafter about 1.6 s whilesession/closesucceeds.- The run's event stream then fails with
ProviderAdapterEventStreamError … Workspace changed., logged as "orchestration V2 provider event ingestion failed". - The ingestion-failure handler in
RunExecutionService.ts(around line 1734) callssession.interruptTurnagain withrequestRuntimeRestart: truebefore writing the failed terminal. That secondAcpAdapterV2.interruptTurnspan never ends, so the terminal write after it never runs.
My guess, which I haven't verified: the first interrupt is cut off while it holds runtimeTransitionPermit, or its transition fiber is forked into the session scope the detach just closed. The second interrupt then waits on the permit forever. Claude and Muse don't hang because their interrupts return, as a success or a failure.
Impact
Major degradation or frequent failure
Version or commit
main at e9e934bb3d, also 65c0195b46
Environment
macOS (Darwin 25.2, arm64), Node 24.18.1, Grok CLI 1.0.77, model grok-4.7-build-fast, full access. Isolated dev server (vp run dev --home-dir <tmp> --no-seed), threads driven with t3 thread start/send.
Logs or stack traces
WARN orchestration V2 provider event ingestion failed
RunExecutionIngestError: Failed while ingesting orchestration V2 run execution run:thread:mcp%3A…:ordinal:2.
[cause]: ProviderAdapterEventStreamError: Failed while streaming grok provider session … events.
[cause]: Error: Workspace changed.
Workaround
None found. I didn't try Stop.
Related: #22971 (the same hand-off ends failed for Claude), #24545 (the fix for Codex), #22825 (a draft that waits for the turn's terminal on detach).
- Lenguaje dominante
- TypeScript
- Estrellas
- 24.8k
- Forks
- 6.4k
- Merge medio
- 4 h 16 min
- PR fusionados (30 d)
- 352
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de pingdotgg/t3code
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
Todos los issues de pingdotgg/t3code
Issues similares
-
Autocomplete still accepts an option after becoming disabledPosiblemente ocupada @Xapollon430 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
reduxjs/react-redux#2416 · 1 comentario ·