Repository navigation
opencode2 service startup fails while V1 migration scans a large SQLite database #41739
Description
Summary
opencode2 cannot start its background service when migrating a large existing SQLite database. The CLI reports that the server exited after roughly 12 seconds, while the detached server process remains alive in disk wait and scans the database for about an hour. It eventually exits, the service remains stopped, and retrying reproduces the problem.
I searched existing issues and found #41346, but this appears distinct: there is no SQLite syntax error here; startup stalls on a very large database and the client/server lifecycle leaves the service unavailable.
Environment
opencode2 v0.0.0-next-17155- Node.js
v26.4.0 - Linux
6.1.175-219.359.amzn2023.aarch64(aarch64) - XFS filesystem
- Existing DB:
~/.local/share/opencode/opencode.db - DB size: 29,889,863,680 bytes (~28 GiB), fully allocated
- SQLite page size/count: 4096 / 7,297,330
- Journal mode: WAL
Reproduction
- Have an existing large
~/.local/share/opencode/opencode.db(about 28 GiB in this case). - Run
opencode2. - Observe:
Starting background server...
ERROR (#1): Error: Server process exited with code 1
at map (native:1:11)
at <anonymous> (../client/src/effect/service.ts:112:30)
at service.ensure (src/services/server-connection.ts:66:53)
opencode2 service statusreportsstopped.- Despite the CLI error,
opencode2.exe serve --serviceremains running. It stays mostly in LinuxDstate (folio_wait_bit_common) and continues reading the DB. During one observation,read_bytesincreased from 67 MB to 294 MB, confirming ongoing I/O. - After about an hour, that process exits. The service is still stopped, and another
opencode2attempt fails the same way.
A concurrent standalone attempt also failed because the first process held the DB lock:
V1 migration failed
EffectDrizzleQueryError: Failed query: INSERT OR IGNORE INTO project ...
SQLiteError: database is locked
That lock error is secondary; it occurred only because the original detached migration process was still running.
Expected behavior
The migration should complete and the service should become available. For large databases, startup should either:
- wait without incorrectly reporting that the server exited,
- expose migration progress/status, or
- fail with an actionable diagnostic.
It should not leave a detached migration process running for an extended period while service status reports stopped.
Actual behavior
The UI cannot start, the CLI says the server exited, a detached process continues scanning the database, and the service never reaches a usable state. Retrying can create lock contention with the still-running migration.
Additional notes
The existing data has been preserved for further diagnostics. I can run targeted, non-destructive SQLite queries if table-level information would help identify why the DB is this large or where migration time is spent.
Activity
opencode-agent commentedon Aug 11, 2026
Could you use
sqlite3against the preserved database and tell us how many rows are in theeventtable? A read-only command is:Given the database size, this query may also take a while.
tsah commentedon Aug 11, 2026
(agent) I ran the read-only query against the preserved database backup:
Result: 880,544 rows.
Timing: 7m33.677s wall time (
0m0.020suser,0m0.224ssys). The original DB remains preserved and unchanged.davispuh commentedon Oct 8, 2026
I have exactly same issue. I was using OpenCode V1 and everything was working fine, but now I updated to V2 and:
I don't know what's correct/best way to recover from this but I tried bunch of things and eventually it succeeded and everything started working.
I think it would be best if there was simple command
opencode migratethat could be ran alone without anything else and let it finish however long it takes (could be hours).joe-ieta commentedon Oct 19, 2026
Description
Confirmed migration error on Windows x64, not a feature request. Reopening Desktop kept reaching a failed background service:
The user reported 2.0.23 after upgrading from 1.x; the exported diagnostic bundle identifies 2.0.32. They returned to 1.19.3.
Read-only snapshot after the incident: database 14,942,654,464 bytes (~13.9 GiB), 3,648,109 pages, 3,322,094 free pages (~91%), and 165 sessions in each of
sessionandsession_v2. Migration was already marked completed at inspection; the event-row count at the original failure is unknown.Steps to reproduce the confirmed cleanup defect
BEFORE DELETEtrigger that raisesABORTonevent_1001, then start V2.error; reopening the database still finds 2,500 events. The first 1,000 deletions rolled back because every batch shares one transaction.The regression test is here. Run from
packages/core:This establishes the transaction/recovery defect, not the underlying filesystem cause of the original I/O error. #41781 is closed and unmerged; a focused fix will keep existing cleanup semantics and only commit its batches separately.