Summary
The devin-cli stats source importer cannot reliably scan the Devin CLI state database on an active workstation: the database grows to ~13 GB and the importer's bounded time budget (import_sqlite_time_limit, ~60 s) is exceeded whenever the owning session keeps a large WAL outstanding. stats-sync correctly refuses the incomplete scan (stats_sync_incomplete_source, exempt/non-poisoning), so publication retries on the next cycle — but on a busy machine the client may be skipped on most fires.
Observed evidence (2026-09-21, production path)
state.vscdb (Devin CLI session DB): ~13 GB main file with a WAL regrowing at roughly ~50 MB/min while a Devin session is active.sqlite3 wal_checkpoint(TRUNCATE) cannot reclaim the WAL while the session holds the DB (busy).- Scheduled cycle output:
aicharts: source=devin-cli code=import_sqlite_read_failed
aicharts: source=devin-cli code=import_sqlite_schema_unreadable
aicharts: source=devin-cli code=import_sqlite_time_limit
aicharts: source=devin-cli code=stats_import_incomplete
{"status":"partial_failure","steps":[..., {"client":"devin-cli","error":"stats_sync_incomplete_source","status":"failed"}]}
- The same source imports successfully when the owning session is idle (257,775 records over a 5-day window in a clean run).
Why it matters
The scheduled publisher skips the client for that day rather than publishing a partial scan — which is the right safety behavior — but the effective reliability depends on the source being quiet at fire time. A 13 GB live database with a hot WAL is the common case for an always-on agent host.
Possible directions
- Read the DB through a WAL-aware snapshot (
VACUUM INTO/backup API into a bounded temp copy) instead of scanning the live file, so the importer is insensitive to concurrent writers and checkpoint timing.
- Chunked/incremental import bounded per day rather than per whole source, so a large DB amortizes across the budget.
- Expose the import budget so operators can raise it for known-large sources.
Summary
The
devin-clistats source importer cannot reliably scan the Devin CLI state database on an active workstation: the database grows to ~13 GB and the importer's bounded time budget (import_sqlite_time_limit, ~60 s) is exceeded whenever the owning session keeps a large WAL outstanding.stats-synccorrectly refuses the incomplete scan (stats_sync_incomplete_source, exempt/non-poisoning), so publication retries on the next cycle — but on a busy machine the client may be skipped on most fires.Observed evidence (2026-09-21, production path)
state.vscdb(Devin CLI session DB): ~13 GB main file with a WAL regrowing at roughly ~50 MB/min while a Devin session is active.sqlite3 wal_checkpoint(TRUNCATE)cannot reclaim the WAL while the session holds the DB (busy).Why it matters
The scheduled publisher skips the client for that day rather than publishing a partial scan — which is the right safety behavior — but the effective reliability depends on the source being quiet at fire time. A 13 GB live database with a hot WAL is the common case for an always-on agent host.
Possible directions
VACUUM INTO/backup API into a bounded temp copy) instead of scanning the live file, so the importer is insensitive to concurrent writers and checkpoint timing.