Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Bug]: Desktop utility bootstrap blocks on thread-goal and queue recovery, then times out after 600000ms

Aberta
  • Algo errado?
#512 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
sqlite, typescript
Domínio
backend, desktop

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

  1. Use MiniMax Code Desktop 3.1.3-inside.122 on macOS arm64 with an existing local runtime profile.
  2. Leave one thread goal with status=active and kickoff_state=consumed, and leave a small number of queue rows with status=queued (one of them source=thread-goal for that goal, plus a few ordinary queued turns on other sessions).
  3. Quit and relaunch the desktop app.
  4. Watch ~/Library/Logs/MiniMax/main-*.log for UtilityRuntime bootstrap 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".
Linguagem predominante
TypeScript
Estrelas
2k
Forks
259
Merge médio
13h 16min
PRs com merge (30d)
63

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de MiniMax-AI/minimax-code

Todas as issues de MiniMax-AI/minimax-code

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.