OOM crash on startup: Event table snapshot + session revert data grow to 1.4GB, sidecar V8 process runs out of memory

Problem

OpenCode Desktop app (v1.18.4, macOS) crashes immediately on startup with OOM error in V8: Zone Allocation failed - process out of memory. The sidecar utility process exits with code 5 before the app becomes usable, leaving the renderer with Failed to load sessions TypeError: Failed to fetch.

Root Cause

The sidecar Node.js process loads the full SQLite database into V8 heap during initialization. Two data fields can grow extremely large for long-running sessions:

1. Event table — session.updated.1 snapshot events

The event-sourcing system stores per-session state in the event table with type session.updated.1. For a single session with ~2300 messages, 361 snapshot events accumulated totaling 423 MB, with the latest single event being 423 MB (LENGTH(data) = 423,582,985).

2. Session table — revert column

The session table has a revert column storing undo/rollback state. For the same session, this field grew to 423 MB (LENGTH(revert) = 423,582,308).

Combined, these two fields added ~850 MB of data, pushing the database to 1.4 GB and causing the V8 utility process to OOM on an 8 GB machine.

Evidence

Server log — V8 OOM on every startup:

[OOM error in V8: Zone Allocation failed - process out of memory]
[Mark-Compact 2488.5 (2541.0) -> 1653.9 (1732.3) MB]

SQLite data:

sqlite> SELECT type, COUNT(*), SUM(LENGTH(data)) FROM event WHERE aggregate_id = ? GROUP BY type;
session.updated.1|361|423825317
message.updated.1|3924|301396010

sqlite> SELECT id, LENGTH(revert) FROM session ORDER BY 2 DESC LIMIT 1;
ses_1634c9ccbffeTB36yzKdrsFVpV|423582308

Discussion

• session.updated.1 events are state snapshots in the event-sourcing pattern. Messages and parts are stored independently in the message and part tables, so the snapshot is a performance optimization, not the source of truth. Deleting oversized snapshots restored normal operation with all 4536 messages across 38 sessions intact.

• The revert column stores serialized undo state. A single 423 MB revert payload suggests unbounded growth with no pruning mechanism.

Suggestions

1. Cap snapshot/compaction sizes: Implement a configurable or hard limit on session.updated.1 event data size. When compaction produces a snapshot over a threshold, skip storing it and fall back to replaying individual events.

2. Revert data limits: Cap or periodically prune the revert field. A 400 MB+ revert payload for one session is unusable.

3. Graceful startup: If the database is too large to fit in available V8 heap, consider loading sessions lazily or showing a cleanup prompt instead of crashing the sidecar.

Workaround

For users hitting this:

1. Backup: cp ~/.local/share/opencode/opencode.db ~/Desktop/opencode.db.backup
2. Delete oversized snapshot events and revert data, then VACUUM.
3. App starts normally with all conversation data intact.