kepr / 3a588182cd3c

handleComplete no longer runs retention.pruneRepo synchronously inside the save transaction — every accepted operator save already enqueues an async .prune job (background.onSaveAccepted, deduplicated per repo) that calls the identical function moments later under its own lock, so the sync call was redundant work (a full two-lane history scan plus a prune cycle) held under the single global connection lock on ~every save past max_snapshots, which was the dominant cost of a bulk koh offer --all push. Preserved the retention.prune_on_offer config knob's meaning by threading it into onSaveAccepted's new prune_enabled param instead of letting it go dead. handleComplete's max_snapshots param is now unused and removed (and all call sites updated). Verified with a real throwaway Postgres (not just the no-PG skip path) against both the working tree and the pre-change checkpoint: same 635/638 pass, 3 known pre-existing failures unrelated to this change (reproduced identically on both). Bump to v1.56.209

dev · 5 weeks ago · 2026-07-16 · 15.1 MB

session: phase A async-only retention prune · agent: claude-sonnet-5

parent: 53073c6db8b5