release(): add per-app mutex — concurrent releases can interleave on the shared engine clone #8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found by the two-lineage crown-jewel review (Fable + Terra), 2026-07-11. Pre-existing gap, not introduced by #4 — so it does not block #4, but both reviewers want it as a fast-follow.
Problem
release()runs on a single shared engine clone on sol-prod and doesfetch → checkout <source> → merge/push → checkout <deploy> → merge --ff-only → push. There is no per-app mutex around this sequence. Tworelease-app <same-app>invocations (or a release racing coordinator-tick) can interleave their checkouts/merges on the one working tree and corrupt branch state or push a wrong tree.The
--ff-onlyfix in #4 makes a bad push fail loudly instead of silently, which narrows the blast radius — but it does not serialize concurrent releases.Fix
Wrap the per-app critical section of
release()in a per-app advisory lock (e.g.flockon/tmp/kua-deploy-release-<app>.lock, or an in-process async mutex keyed by app). Second concurrent release for the same app should queue or fail fast with a clear "release already in progress" error, never interleave. Different apps may still release in parallel.Acceptance
release()calls for the same app serialize (second waits or errors clearly); a test proves no interleaving.