Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#512 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
sqlite, typescript
Lĩnh vực
backend, desktop

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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".
Ngôn ngữ chính
TypeScript
Star
2k
Fork
259
Merge trung bình
9 giờ 22 phút
Pull request đã merge (30 ngày)
105

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MiniMax-AI/minimax-code

Tất cả issue của MiniMax-AI/minimax-code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.