Description
On upgrade, the V1→V2 session history migration crashes every boot with RangeError: Out of memory when an old-schema session contains a very large embedded file part. In my case: a part row of ~279 MB whose data is {"type":"file","mime":"application/pdf","url":"data:application/pdf;base64,..."} (same PDF attached 4x across sessions, plus two ~56 MB blobs). The migration retries from scratch on every server start and dies on the same session, each attempt re-projecting rows into session_message, growing the db to 3.5 GB.
The migration already has a "Skipped V1 migration row" warning path, but it never triggers for these. Suggested fix: process parts without materializing the whole value (stream/omit the blob), or skip parts above a size threshold instead of OOM.
Plugins
- local plugin:
~/.config/opencode/plugins/openviking
opencode-antigravity-auth@latest (V1-only, fails to load — unrelated)superpowers (git)
OpenCode version
2.0.11 (first observed) and 2.0.12 (verified after workaround)
Steps to reproduce
- Have an old-schema session (db with
session/message/part tables from a pre-V2 build) containing an attached ~280 MB PDF stored as a base64 data: URL part
- Upgrade to 2.0.x so the V1→V2 session history migration runs
- Start the server
Actual, every boot:
level=ERROR message="V1 migration failed" cause="Cause([Die(RangeError: Out of memory)])"
- TUI banner:
Data migration failed: Out of memory
GET /api/experimental/migration/v1 → {"status":"error","error":"Out of memory"}part table: 162k rows / 1.8 GB, single largest LENGTH(data) ≈ 292 MB
Workaround (confirmed): back up the db, DELETE FROM part WHERE LENGTH(data) > 10485760 (and the already-projected session_message copies), restart → migration finishes and the endpoint reports {"status":"completed"}.
Screenshot and/or share link
n/a
Operating System
macOS (Darwin 25.6.0, arm64)
Terminal
Ghostty
Description
On upgrade, the V1→V2 session history migration crashes every boot with
RangeError: Out of memorywhen an old-schema session contains a very large embedded file part. In my case: apartrow of ~279 MB whosedatais{"type":"file","mime":"application/pdf","url":"data:application/pdf;base64,..."}(same PDF attached 4x across sessions, plus two ~56 MB blobs). The migration retries from scratch on every server start and dies on the same session, each attempt re-projecting rows intosession_message, growing the db to 3.5 GB.The migration already has a "Skipped V1 migration row" warning path, but it never triggers for these. Suggested fix: process parts without materializing the whole value (stream/omit the blob), or skip parts above a size threshold instead of OOM.
Plugins
~/.config/opencode/plugins/openvikingopencode-antigravity-auth@latest(V1-only, fails to load — unrelated)superpowers(git)OpenCode version
2.0.11 (first observed) and 2.0.12 (verified after workaround)
Steps to reproduce
session/message/parttables from a pre-V2 build) containing an attached ~280 MB PDF stored as a base64data:URL partActual, every boot:
Data migration failed: Out of memoryGET /api/experimental/migration/v1→{"status":"error","error":"Out of memory"}parttable: 162k rows / 1.8 GB, single largestLENGTH(data)≈ 292 MBWorkaround (confirmed): back up the db,
DELETE FROM part WHERE LENGTH(data) > 10485760(and the already-projectedsession_messagecopies), restart → migration finishes and the endpoint reports{"status":"completed"}.Screenshot and/or share link
n/a
Operating System
macOS (Darwin 25.6.0, arm64)
Terminal
Ghostty