Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#512 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
sqlite, typescript
Domain
backend, desktop

Research direction

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.

Written by the indexing model from the issue text.

Description

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".
Dominant language
TypeScript
Stars
2k
Forks
259
Avg merge
9h 22m
Merged PRs (30d)
105

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MiniMax-AI/minimax-code

All issues in MiniMax-AI/minimax-code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.