api: atomically guard concurrent deploys for one app (#309) #350
fix/many-git-push-deploy into main @ -0,0 +179,4 @@
# ── Step 4: Race the state CAS on the destroyed-app branch ───────────
#
# Mirrors api/src/main.rs deploy_logic (was_destroyed branch). Two concurrent
Not sure we should be touching the DB directly. This pulls the logic out of main.rs, and places it into here. If we change main.rs, it might not show up here. Is there a way we can start a git push, terminate it partway through, then start another git push, and see if that errors?
I think we can't aim for the right window from outside.
We could extract the guard SQL into a shared constant that both main.rs and the test reference, so any change to it breaks the test, but a bandaid.
or we do both? add a kill and retry test + keep this?
I think this introduces too much test-specific logic for me to be happy with. I think the SQL logic looks good, but I don't think this test is sufficient enough at being a test. I would rather we remove it and manually test the endpoint instead.
57a8da53a7
to 03ab2a24e1
No due date set.
No dependencies set.
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?