You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Investigate and fix the concrete checkpoint delta omission found during #2333, rather than retuning SQLite's pool. At 2f5f987a, cloneFileSnapshot does not copy Checkpoints, although deltaSQLiteCheckpointRows compares the old/new checkpoint maps. The #2333 baseline measures 13 / 103 / 1003 SQL row changes for one run mutation with 10 / 100 / 1000 resident checkpoints. This proves write amplification in the declared workload; cleanup durability still needs an independent red test. Further source inspection found a second omission: Store.removeRunEvidence does not delete checkpoints when deleting a thread or pruning a run. The reproduction must therefore check both memory cleanup and durable deletion; do not assume memory cleanup already works.
Scope / Files / File Ownership
One local writer, independent from the benchmark PR #2334:
edge-server/internal/store/sqlite_store_query.go: preserve a deep-cloned checkpoint map in the committed delta baseline, if the red tests confirm the omission.
edge-server/internal/store/store_projects.go: remove the run-owned checkpoint at the existing shared evidence-pruning boundary, if the lifecycle regression confirms the omission.
docs/architecture/02-edge-server.md: synchronize the existing cascade description with the verified checkpoint behavior.
edge-server/internal/store/sqlite_store_query_test.go: extend the existing clone ownership/immutability test rather than add a mirror-of-fields test.
edge-server/internal/store/sqlite_checkpoint_delta_test.go: real SQLite regressions for unchanged checkpoint rewrites and checkpoint deletion surviving run cleanup and reopen.
No connection-pool, PRAGMA, schema/migration, API, background timer, FileStore, benchmark or live-service changes.
Interfaces / Invariants
Retain current public signatures and update the delta baseline only after successful transaction commit. Reuse cloneCheckpointMap, including nested Files ownership. Legitimate checkpoint updates must still persist; retained runs/checkpoints must survive cleanup of a different terminal run. Do not mask missing durable writes with a final Close/Flush before validating the database.
Acceptance
Reproduce on the starting code: a real SQLite audit trigger observes rewriting unchanged checkpoint rows after an unrelated run mutation; terminal-run cleanup and thread deletion must remove the checkpoint both in memory and in its persisted row, and keep it absent through reopen. Record actual red output before any production edit.
Minimal fix plus existing clone test verifies nested checkpoint files are not shared.
Green regressions include a legitimate checkpoint content update (audit sensitivity), preservation of the unrelated checkpoint, and actual reopen before an extra final Close flush.
Full store-package Linux race, Windows store tests, vet/staticcheck and all required PR checks pass. Preserve unrelated WIP.
Only local disposable SQLite fixtures. No user data, production database repair, deployment or live performance claim. No automatic deletion of historical persisted orphans: any existing-data cleanup is a separate migration/repair decision. Benchmark tooling is #2334; the correctness regression is independently runnable on the current mainline.
Summary
Investigate and fix the concrete checkpoint delta omission found during #2333, rather than retuning SQLite's pool. At
2f5f987a,cloneFileSnapshotdoes not copyCheckpoints, althoughdeltaSQLiteCheckpointRowscompares the old/new checkpoint maps. The #2333 baseline measures 13 / 103 / 1003 SQL row changes for one run mutation with 10 / 100 / 1000 resident checkpoints. This proves write amplification in the declared workload; cleanup durability still needs an independent red test. Further source inspection found a second omission:Store.removeRunEvidencedoes not delete checkpoints when deleting a thread or pruning a run. The reproduction must therefore check both memory cleanup and durable deletion; do not assume memory cleanup already works.Scope / Files / File Ownership
One local writer, independent from the benchmark PR #2334:
edge-server/internal/store/sqlite_store_query.go: preserve a deep-cloned checkpoint map in the committed delta baseline, if the red tests confirm the omission.edge-server/internal/store/store_projects.go: remove the run-owned checkpoint at the existing shared evidence-pruning boundary, if the lifecycle regression confirms the omission.docs/architecture/02-edge-server.md: synchronize the existing cascade description with the verified checkpoint behavior.edge-server/internal/store/sqlite_store_query_test.go: extend the existing clone ownership/immutability test rather than add a mirror-of-fields test.edge-server/internal/store/sqlite_checkpoint_delta_test.go: real SQLite regressions for unchanged checkpoint rewrites and checkpoint deletion surviving run cleanup and reopen.No connection-pool, PRAGMA, schema/migration, API, background timer, FileStore, benchmark or live-service changes.
Interfaces / Invariants
Retain current public signatures and update the delta baseline only after successful transaction commit. Reuse
cloneCheckpointMap, including nested Files ownership. Legitimate checkpoint updates must still persist; retained runs/checkpoints must survive cleanup of a different terminal run. Do not mask missing durable writes with a final Close/Flush before validating the database.Acceptance
Negative Constraints / Dependencies
Only local disposable SQLite fixtures. No user data, production database repair, deployment or live performance claim. No automatic deletion of historical persisted orphans: any existing-data cleanup is a separate migration/repair decision. Benchmark tooling is #2334; the correctness regression is independently runnable on the current mainline.