migrate: V1→V2 session history migration OOMs on sessions with huge base64 file parts #50339

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

1. 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
2. Upgrade to 2.0.x so the V1→V2 session history migration runs
3. 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