Context
POST /snapshots inserts a new row into snapshots and compacts events. GET /snapshots/latest returns ORDER BY up_to_seq DESC LIMIT 1 (src/store/sync.ts:88).
Problem / Observation
Old snapshot rows are never deleted. Each successful snapshot upload (up to 1 MiB) is retained forever. Over time, the snapshots table grows unbounded, with N-1 entries that no code path ever reads. There is no migration mechanism if a future schema needs to reformat them either.
Proposed approach
In putSnapshotAndCompact (see related atomicity issue), after inserting the new snapshot, DELETE earlier snapshots for the same user. Keep only the latest. If the operator wants point-in-time recovery, that's the cold-backup story, not a per-user retention buffer.
Alternatively, keep the previous one (N=2) as belt-and-suspenders against a corrupted upload, but no more.
Acceptance criteria
Context
POST /snapshotsinserts a new row intosnapshotsand compacts events.GET /snapshots/latestreturnsORDER BY up_to_seq DESC LIMIT 1(src/store/sync.ts:88).Problem / Observation
Old snapshot rows are never deleted. Each successful snapshot upload (up to 1 MiB) is retained forever. Over time, the snapshots table grows unbounded, with N-1 entries that no code path ever reads. There is no migration mechanism if a future schema needs to reformat them either.
Proposed approach
In
putSnapshotAndCompact(see related atomicity issue), after inserting the new snapshot, DELETE earlier snapshots for the same user. Keep only the latest. If the operator wants point-in-time recovery, that's the cold-backup story, not a per-user retention buffer.Alternatively, keep the previous one (N=2) as belt-and-suspenders against a corrupted upload, but no more.
Acceptance criteria