[Bug]: Desktop utility bootstrap blocks on thread-goal and queue recovery, then times out after 600000ms
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
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- sqlite, typescript
Línea de trabajo
Start by tracing utility bootstrap from the modules-loaded stage through services.ready(), conversation.bind(), and bindExternalChannelSubsystem; inspect recoverThreadGoalKickoffs() and the startup dispatch from listPendingSessionIds(). Reproduce with an active consumed thread goal and queued or claimed rows, then confirm bootstrap reaches sqlite-ready and ready without waiting on recovery, while recovery failures do not block readiness.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Product or interface
Desktop app
Version
3.1.3-inside.122
Platform
macOS
OS version and architecture
macOS 27.0.1 (26A434), arm64
Issue area
Startup / install / update
Desktop log upload ID
453999839174989
Uploaded from Settings on 2026-10-20. Raw session files are not pasted here.
Steps to reproduce
- Use MiniMax Code Desktop 3.1.3-inside.122 on macOS arm64 with an existing local runtime profile.
- Leave one thread goal with
status=activeandkickoff_state=consumed, and leave a small number of queue rows withstatus=queued(one of themsource=thread-goalfor that goal, plus a few ordinary queued turns on other sessions). - Quit and relaunch the desktop app.
- Watch
~/Library/Logs/MiniMax/main-*.logforUtilityRuntimebootstrap progress.
Expected and actual behavior
Expected: the utility process reaches sqlite-ready and reports ready within a few seconds. Recovering an active thread goal or draining queued turns must not block process readiness. A cloud request that does not return should time out and be retried after the runtime is ready.
Actual: bootstrap reaches modules-loaded in about 1.5s, logs sandbox.lifecycle_changed with runtime_state=disabled, and then never logs External channel subsystem bound to the v1 host facade or stage=sqlite-ready. The utility process stays alive at about 0% CPU with an established TCP connection to agent.minimax.cn:443. After exactly 600000ms the supervisor logs:
[UtilityRuntime] bootstrap stalled at stage modules-loaded for 600000ms (1/3); killing utility process
The user-visible error is utility bootstrap timed out after 600000ms. Each relaunch repeats the same stall. The 600000ms value matches BOOTSTRAP_STALL_TIMEOUT_MS: the watchdog measures silence since the last bootstrap stage, and nothing between modules-loaded and sqlite-ready reports progress.
Workaround that unblocked this profile: pause that active thread goal (do not delete it) and remove the queued/claimed queue rows, then relaunch. The next boot logged sqlite-ready at 1790ms and ready at total=2298ms. No session content was required for the workaround; only the durable goal status and queue-item status mattered.
Redacted error summary
[UtilityRuntime] bootstrap progress stage=node-entry elapsed=170ms
[UtilityRuntime] bootstrap progress stage=modules-common-done elapsed=1182ms
[UtilityRuntime] bootstrap progress stage=modules-runtime-v2-done elapsed=1515ms
[UtilityRuntime] bootstrap progress stage=modules-loaded elapsed=1515ms
... sandbox.lifecycle_changed runtime_state=disabled ...
# no further bootstrap stage for 600000ms
[UtilityRuntime] bootstrap stalled at stage modules-loaded for 600000ms (1/3); killing utility process
utility bootstrap timed out after 600000ms
# after pausing the active goal and clearing queued rows:
[UtilityRuntime] bootstrap progress stage=sqlite-ready elapsed=1790ms since_previous=293ms
[UtilityRuntime] ready total=2298ms preparation=479ms bootstrap=1819ms
Notes for triage
The hang is on the desktop local-runtime utility, after modules are loaded and after the sandbox service has published runtime_state=disabled, and before bindExternalChannelSubsystem. That window includes services.ready(), and conversation.bind() awaits recoverThreadGoalKickoffs() while startup execution is enabled. listRecoverableActiveGoals() selects rows with kickoff_state=consumed and status=active. Separately, authenticated startup recovery dispatches every session returned by listPendingSessionIds() (status queued or claimed) and awaits that dispatch.
Please treat the causal link as: removing those durable rows made an otherwise identical boot finish in about 2s, and during the hang the only useful external activity was a TCP connection to agent.minimax.cn that never completed. A JavaScript stack at the time showed an idle event loop, so the blocked wait is likely a native request without a bootstrap-scoped deadline.
Suggested change:
- Do not await thread-goal continuation or queue dispatch before reporting
sqlite-ready. Run that recovery after ready, detached, the same way owner channel startup already is. - Give any cloud call that can still overlap bootstrap a short timeout, and fail open.
- Emit a bootstrap progress stage for the recovery step, so a stall names "goal recovery" or "queue dispatch" instead of only "modules-loaded".
- Lenguaje dominante
- TypeScript
- Estrellas
- 2k
- Forks
- 259
- Merge medio
- 9 h 22 min
- PR fusionados (30 d)
- 105
Preparar el entorno
- 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 MiniMax-AI/minimax-code
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
MiniMax-AI/minimax-code#507 ·
Los mantenedores suelen responder en 1 día
-
bug needs-triage tui
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
MiniMax-AI/minimax-code#481 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug cli documentation needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
MiniMax-AI/minimax-code#299 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
MiniMax-AI/minimax-code#521 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
MiniMax-AI/minimax-code#520 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de MiniMax-AI/minimax-code
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
endora-commerce/endora-commerce#397 ·
Los mantenedores suelen responder en 1 día
-
level/task
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
wazuh/wazuh-dashboard-plugins#9472 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
Los mantenedores suelen responder en 1 día
-
ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
xavxyz/bei-shan-lin-shui#57 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
opennextjs/opennextjs-cloudflare#1461 ·
Los mantenedores suelen responder en 1 día