Skip to content

fix(store): prune run checkpoints and persist their delta state #2335

Description

@DeliciousBuding

Summary

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

  1. 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.
  2. Minimal fix plus existing clone test verifies nested checkpoint files are not shared.
  3. Green regressions include a legitimate checkpoint content update (audit sensitivity), preservation of the unrelated checkpoint, and actual reopen before an extra final Close flush.
  4. Full store-package Linux race, Windows store tests, vet/staticcheck and all required PR checks pass. Preserve unrelated WIP.
  5. Reuse the merged test(store): benchmark snapshot persistence and SQLite facade contention #2334 workload for a matching-scope before/after check: report row-change delta and timing without promising production gains. Do not change the fixture to improve the result.
  6. Update perf(store): measure snapshot persistence and real SQLite facade contention #2333/后端性能候选收口:限定测量与 ctx / checkpoint 修复完成 #2256 with the reproduced outcome and linked fix, then clean the merged task worktree/branch.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions