[Bug]: Native Chat journal grows to ~20 GiB; request supported compaction of superseded revisions #34916

Observed behavior

Native Chat's agent-session-journal.db grew to approximately 19.94 GiB, containing:

• 310 sessions
• 2,578,668 journal rows
• 80 retained chat tabs

The goal is to control journal size while preserving usable conversation history, without having to delete entire sessions.

Environment

• Windows
• Orca 1.4.243
• Installed build commit: 2d9b5957851e5bd449e179018e53759ea69e3f0b

Findings

In this database, multiple revisions of the same item store substantial amounts of repeated or progressively growing content. Large fields in older revisions continue to occupy storage even after those revisions have been superseded.

These rows do not all represent separate user messages. However, intermediate revisions cannot simply be treated as worthless: some older revisions contain longer outputs than the final, truncated versions.

Offline compaction experiment

After making a complete backup, an experiment was performed on a database copy:

• Retained all sessions and journal rows.
• Left seq, epoch, and revision unchanged.
• Cleared only selected large fields in older item revisions superseded by higher revisions.
• Preserved final item rows, other events, and other tables.
• Modified 1,825,969 rows and compacted the result into a new database.

Database size decreased by approximately 77.24%.

Completed validation

Comparisons used the reader and replay logic from the same commit as the installed build:

• Final replay states and snapshots matched for all 310/310 sessions.
• Replay reported no damaged or newer-version states.
• Three large sessions passed append, reopen in a separate process, and continued-write tests in isolated test databases.
• A subsequent quick_check on the live database returned ok; sequence continuity checks passed.

Important limitations

This was an experiment on a specific database and version, not a generally safe migration procedure.

Identical final replay states do not mean that all historical information was preserved losslessly. Clearing fields in older revisions discards intermediate-version content, including output that may not survive in the final truncated version. These checks also do not establish compatibility with every UI, export, recovery, or future-version migration path.

The resulting database has been installed locally, but comprehensive chat interaction, repeated-restart, and long-term usage validation have not been completed. Other users should therefore not directly copy the SQL or cleanup scripts at this stage.

Questions for maintainers

1. Which revision fields are used only to reconstruct current state, and which are still needed by history viewing, recovery, or other features?
2. Could Orca provide an official journal compaction tool that explicitly defines which history it preserves and which information it discards?
3. Could checkpoints, incremental storage, or another mechanism avoid repeatedly persisting large content blocks during streaming updates?
4. Could official compaction include dry-run statistics, backups, replay-equivalence validation, and a rollback procedure?

I can provide sanitized analysis methods and validation logic. Chat databases, message contents, account identifiers, and attachments will not be shared publicly.

Related PRs

• perf(native-chat): save new reply text without copying the growing reply #32315 — Directly related to repeated persistence of growing replies. The PR saves new assistant/reasoning text pieces, retains authoritative whole replies, and retires superseded pieces. This report adds evidence from an existing large journal and requests a supported compaction/recovery path with explicit historical-information retention guarantees. It does not establish that the PR will reclaim this existing database or preserve every intermediate revision.
• Startup shows chats as Interrupted or Done without reading their history #32146 — Related to the startup cost of large saved histories: it lists chats from metadata and loads history on demand instead of replaying all open chats at startup. This addresses startup replay/memory pressure; it should not be taken as evidence that existing journal files will shrink.

Both PRs were open when these references were added. Their descriptions and validation limits remain the source of truth; this report does not claim either change is included in Orca 1.4.243 or that either resolves all aspects of this issue.