OOM and ~30 GB database: huge workspace-file diffs embedded in message summaries are re-serialized in full on every `message.updated` event

[isHarryh]

Description

When a text file in the OpenCode workspace keeps growing while a session is running (in my case an MCP server continuously appending its full API request/response log into the workspace — two log files reached 292 MB and 407 MB), OpenCode tracks the change and embeds the file's diff into message.summary.diffs on user messages.

This is compounded by the event store: every message.updated event re-serializes the entire message payload — including the huge embedded diff — as a new row in the event table. The same message is updated hundreds of times during a session, so the same multi-hundred-MB payload is written over and over.

Results:

• opencode.db grew to 32.9 GB (event table alone: 29.4 GB)
• OpenCode eventually crashed with OOM
• Resuming the session crashes again with OOM, so the problematic session is permanently unopenable

Analysis

Measured on the 32.9 GB database:

table	size
event	29,407 MB
message	1,121 MB
part	510 MB
WAL	771 MB

• event holds 513k rows; 97.6% were written within ~8 hours.
• Largest single event row: 362 MB (message.updated.1). Payload begins:
  {"sessionID":"ses_A","info":{...,"role":"user","summary":{"diffs":[{"file":"/logs/api_20260820.jsonl","patch":"Index: ...
  — the full unified diff of the 407 MB log file is embedded in the message.
• 717 events exceed 1 MB (25.5 GB total); 135 events exceed 10 MB.
• Session ses_A: 250 message.updated events for the same message, averaging ~33 MB each → 8.4 GB of byte-identical payloads. Top 3 sessions account for ~24 GB.

Root-cause chain

1. A tool (here: an MCP server) continuously appends to a log file inside the workspace.
2. OpenCode diffs the file against its snapshot and embeds the uncapped diff into message.summary.diffs.
3. Every message.updated event stores a full copy of the message JSON in the event table (no truncation / dedup).
4. The message is updated hundreds of times → hundreds of full-size copies → tens of GB.
5. On session resume, giant messages are deserialized → OOM.

Steps to reproduce

1. Start OpenCode TUI, assign a long task to OpenCode to let it keep running.
2. Create a text file named test.txt in your OpenCode workspace.
3. Start a program that appends 1 MB of text into that file every 1 or 2 seconds.
4. Wait until OOM crash; restarting and resuming the session crashes again.

Diagnostics SQL:

SQL queries used

SELECT name, sum(pgsize)/1048576.0 AS mb FROM dbstat GROUP BY name ORDER BY mb DESC;
SELECT length(data)/1048576 AS mb, type, aggregate_id FROM event ORDER BY length(data) DESC LIMIT 10;
SELECT aggregate_id, count(*), sum(length(data))/1048576 AS mb FROM event GROUP BY aggregate_id ORDER BY mb DESC LIMIT 10;

Plugins

None

OpenCode version

1.18.18

Screenshot and/or share link

The problematic session cannot be opened anymore.

Operating System

Windows 11 (24 GB RAM)

Terminal

Powershell 7.8

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Unbounded growth of the event table: opencode.db reaches 13GB+, mostly message.updated.1 snapshots (no retention/compaction) #33356: Unbounded growth of the event table — opencode.db reaches 13GB+, mostly message.updated.1 snapshots (no retention/compaction)
• Excessive storage: event table stores full message snapshots per streaming update — community tool available #41175: Excessive storage: event table stores full message snapshots per streaming update
• OOM crash on startup: Event table snapshot + session revert data grow to 1.4GB, sidecar V8 process runs out of memory #38362: OOM crash on startup caused by event table snapshot + session revert data growing very large

The root cause appears to be the same: the event table accumulates full message snapshots without any retention or compaction, which your large file being tracked would rapidly accelerate.