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

[Bug] Concurrent mcode processes kill each other's turns: SQLITE_BUSY on shared runtime-state.sqlite

Open
  • Is something wrong?
#282 2 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, databases

Research direction

Reproduce the failure with 5+ concurrent mcode sessions and inspect ~/.minimax/v2/observability/logs/runtime-*.log for the history-delivery or event-writer stage. Then trace the transaction helpers $t, YMe, and transaction(r).immediate() in the bundled chunks around runtime-state.sqlite. Done means concurrent turns no longer abort with SQLITE_BUSY or database-locked errors.

Written by the indexing model from the issue text.

Description

bug cli needs-triage

Summary

When several minimax-code processes run in parallel (common for power users running multiple sessions), turns intermittently die with:

The response failed.
Reason: database is locked

The failure is local, not an upstream API error — the request never reaches the network. From ~/.minimax/v2/observability/logs/runtime-*.log:

[pi-turn-runner] history delivery failed ... SqliteError: database is locked
    at sqliteTransaction (.../better-sqlite3/lib/methods/transaction.js:63:9)
[local-runtime-v2] agent host turn failed ... failure_stage="Agent execution failed."

Root cause

All processes share a single ~/.minimax/v2/sqlite/runtime-state.sqlite (WAL mode). The runtime sets PRAGMA busy_timeout = 5000, but under N concurrent writers a 5s wait is not always enough, and no retry on SQLITE_BUSY exists — the transaction wrapper ($t, YMe, and the goal-repo transaction(r).immediate() call sites in the bundled chunks) throws immediately once the timeout expires. The turn then fails at history delivery / event writer stage and the whole agent turn is aborted.

Observed with 9 concurrent processes on a ~330 MB database; frequency grows with parallelism and DB size.

Suggested fixes (any of)

  1. Retry with backoff on SQLITE_BUSY around the transaction helpers — cheapest, survives arbitrarily long foreign transactions.
  2. Raise busy_timeout (e.g. 30s) — helps but does not cover BUSY_SNAPSHOT cases.
  3. Shard session-scoped tables per session (e.g. runtime-state-<session>.sqlite) while keeping shared tables (local_runtime_agents, local_runtime_communication_messages, local_runtime_queues, local_runtime_crons, local_runtime_background_tasks, local_runtime_session_locks) in a coordinator DB — removes write contention entirely for the hot path. Note: a naive per-session split is not possible because the schema intentionally mixes session-scoped and cross-session coordination tables.

Environment

  • @minimax-ai/code 0.5.0 (npm), Linux x64, Node v24.18.0
  • Repro: run 5+ mcode sessions concurrently with active tool calls; within an hour at least one turn dies with database is locked.
Dominant language
TypeScript
Stars
1.9k
Forks
226
Avg merge
3h 32m
Merged PRs (30d)
122

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.