opencode2 service startup fails while V1 migration scans a large SQLite database

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

1. Have an existing large ~/.local/share/opencode/opencode.db (about 28 GiB in this case).
2. Run opencode2.
3. 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)

4. opencode2 service status reports stopped.
5. Despite the CLI error, opencode2.exe serve --service remains running. It stays mostly in Linux D state (folio_wait_bit_common) and continues reading the DB. During one observation, read_bytes increased from 67 MB to 294 MB, confirming ongoing I/O.
6. After about an hour, that process exits. The service is still stopped, and another opencode2 attempt 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.