Repository navigation
statev2.sqlite grows without bound: 17 GB after 76 days, ~100 MB/hour with seven orchestrators (event log has no retention) #24789
Description
Problem
On one host running seven long-lived orchestrator threads plus their delegated children, ~/.t3/userdata/statev2.sqlite is 17.0 GB (4,155,037 pages at 4 KiB, freelist 0) and grows about 100 MB per hour. Measured read-only on 2026-10-25 (T3 Code 0.1.2):
| table | rows | payload_json |
|---|---|---|
orchestration_events (2026-08-10 → now) |
1,955,433 | 4.93 GB |
of which turn-item.updated |
719,582 | 3.28 GB |
of which node.updated |
668,578 | 0.94 GB |
of which provider-turn.updated |
282,691 | 0.34 GB |
orchestration_v2_projection_turn_items |
418,028 | 2.65 GB |
| other V2 projections | 0.15 GB |
The rest of the file is indexes and per-row overhead. Nothing prunes or compacts, so the file only grows; on this host it is now the largest single file written in a day, and it sits on the same volume as every worktree and CI runner.
Related but different: #18204 (closed) removed subagent-prompt write amplification; #23482 and #23687 are about WAL and reader locking. None covers retention of the append-only event log.
Reproduction
Run several orchestrators with delegated children for a few weeks. Watch select count(*) from orchestration_events and the file size. Archived threads keep their full event history.
Proposed behavior
Keep the event log authoritative but bounded:
- snapshot projections and truncate events older than the snapshot for archived or settled threads, or
- offer a user-triggered compaction (prune, then
VACUUM) with a configurable retained window, and - at minimum, show the file size and growth rate in settings so users see it before the disk does.
Why this belongs in T3
Users cannot safely prune a live SQLite file the server has open (#23482 shows a read transaction alone can freeze writes). Only the server knows which events are replayable from projections.
Activity