Concurrent `biorouter run --no-session` invocations collide on shared messages DB (UNIQUE constraint failed: messages.session_id, messages.msg_uid)

[Broccolito]

Summary

Running two biorouter run --no-session invocations concurrently causes one of them to abort with a SQLite uniqueness error on the shared messages store:

Error: error returned from database: (code: 2067) UNIQUE constraint failed: messages.session_id, messages.msg_uid

Despite passing --no-session, the concurrent runs appear to share (and race on) a common messages/session database, and one run loses the race. The aborted run produces empty/invalid output (no assistant text, 0 tool calls), so with --output-format json the emitted document is effectively empty.

Environment

• biorouter 1.88.3
• macOS (Apple Silicon)
• Invocation: headless biorouter run (no TUI), --no-session, --output-format json

Reproduction

Launch two biorouter run --no-session processes at the same time (here with two different providers/models, but the providers are incidental):

# Terminal A / background job 1
biorouter run --no-session --quiet --output-format json \
  --provider versa_azure --model gpt-5.5-2026-04-24 --max-turns 50 \
  -t "…prompt A…" > a.json 2> a.log &

# Terminal B / background job 2 (started concurrently)
biorouter run --no-session --quiet --output-format json \
  --provider versa_bedrock --model us.anthropic.claude-opus-4-8 --max-turns 50 \
  -t "…prompt B…" > b.json 2> b.log &

Observed

• One run completes normally.
• The other aborts early; its .log (stderr) contains:
  Error: error returned from database: (code: 2067) UNIQUE constraint failed: messages.session_id, messages.msg_uid
• The aborted run's JSON output is empty/unparseable; the run reports success: false with 0 tool calls.
• Running the same two commands sequentially (one after the other) both succeed. The failure only occurs when they overlap in time.

Expected

--no-session runs should not persist to — or contend on — a shared session/messages database, and concurrent headless invocations should be isolated from one another (e.g., per-process/in-memory storage, or unique per-run session ids). At minimum, a lost race on the shared store should be retried or surfaced as a clear, non-fatal condition rather than silently emptying the output.

Impact

This makes it unsafe to run headless biorouter run jobs in parallel (e.g., fanning out a benchmark across models). Users must serialize all biorouter run invocations, even with --no-session. The failure mode is also easy to miss because the run still exits and writes an (empty) output file.

Likely cause (speculation, not a fix)

The (session_id, msg_uid) UNIQUE constraint on a messages table suggests that:

• --no-session still writes conversation messages to a shared on-disk DB, and/or
• concurrent runs derive the same session_id (a default/placeholder rather than a per-run unique id), so their message inserts collide, and/or
• msg_uid generation isn't unique/atomic across concurrent processes.

Filing as a bug / enhancement; not attempting a fix here — just documenting the behavior and reproduction.

[Broccolito]

Update — root cause is broader than "two concurrent CLI runs"

Further testing shows the collision also happens when there is only one biorouter run --no-session CLI invocation — as long as another biorouter process is running concurrently. In my case ps showed the desktop app and its daemons active the whole time:

biorouter acp
biorouterd agent
…/Electron.app/… (BioRouter desktop UI)

All of these write to the same store: ~/.local/share/biorouter/sessions/sessions.db (messages, sessions, … tables). Session ids there are auto-generated as YYYYMMDD_N (a per-day counter). So:

• --no-session does not isolate a CLI run from other biorouter processes (desktop app / biorouterd / acp) — they share sessions.db.
• The YYYYMMDD_N id counter isn't safe against concurrent writers, so two writers land on the same session_id and their msg_uid inserts collide → UNIQUE constraint failed: messages.session_id, messages.msg_uid.
• This is why a single CLI run failed "in isolation": the desktop app was the other writer.

Workaround that works

• --session-id <id> cannot be used to force a fresh isolated run — it's rejected with Error: --session-id can only be used with --resume flag.
• Passing a unique --name per run (e.g. --name "job-$RANDOM$RANDOM") does avoid the collision reliably, even with the desktop app running. Switching a batch of headless runs from --no-session to a unique --name made them all succeed.

Suggestion

--no-session should be genuinely isolated (in-memory or a per-run private DB), and/or session_id allocation should be concurrency-safe across processes so headless runs can coexist with the desktop app. (Filing as bug/enhancement — not attempting a fix.)

[Broccolito]

Additional findings (biorouter 1.88.3, macOS/Apple Silicon): the collision also happens when the desktop GUI is open, a unique --name does not prevent it, and XDG_DATA_HOME isolation is a working fix that also unlocks safe concurrency.

Reproduced repeatedly while running a large automated benchmark (hundreds of sequential biorouter run calls). Three things extend the original report:

1. A unique --name per run does NOT prevent it

We moved off --no-session to a unique --name "<tag>-<q>-<rand>" per invocation (i.e. a distinct session_id per run) specifically to dodge this. The collision still fires:

Error: error returned from database: (code: 2067) UNIQUE constraint failed: messages.session_id, messages.msg_uid

The losing run fast-fails (~15 s), emits (no text response) / 0 tool calls, and --output-format json is effectively empty.

2. The concurrent writer can be the desktop GUI (biorouter acp), not just another biorouter run

The failures correlated with the BioRouter desktop app being open. ps showed a second instance writing the same store:

705  /Users/wgu/Desktop/BioRouter/target/release/biorouter acp

So simply having the GUI / acp running in the background is enough to race a headless CLI run on the shared ~/.local/share/biorouter/sessions/sessions.db. Any two processes that touch that DB — CLI+CLI or CLI+GUI — can collide. This makes the bug easy to hit accidentally: a user runs a headless job while their app is open.

3. Confirmed workaround: per-process XDG_DATA_HOME

Giving each process its own data dir gives each its own sessions.db, which makes the collision structurally impossible — and, as a bonus, lets many runs execute concurrently:

XDG_DATA_HOME=/tmp/run_A biorouter run --quiet --output-format json --provider ... --model ... -t "..." &
XDG_DATA_HOME=/tmp/run_B biorouter run --quiet --output-format json --provider ... --model ... -t "..." &
wait

Verified: two concurrent isolated runs, with the GUI also open, all completed with no UNIQUE error and returned valid answers; the main ~/.local/share/biorouter/sessions/sessions.db was left untouched (mtime unchanged).

4. Side note — DB growth

The shared sessions.db had grown to ~215 MB, which likely widens the write-lock contention window and makes the race easier to hit.

Suggested fixes (any of)

• Open the SQLite session store in WAL mode with a busy_timeout, and retry on SQLITE_BUSY/constraint instead of aborting the run.
• Make --no-session truly not touch the shared DB (temp/in-memory store); key writes by a per-process session so concurrent processes can't share a (session_id, msg_uid) space.
• Or default to per-run DB files / serialize writes through a single writer.
• On this failure, surface a clear message ("another biorouter process is using the session store") rather than a raw SQLite constraint dump — and don't emit empty --output-format json.