Repository navigation
fix(ctf): launch participant ranges outside the assignment transaction - #2523
Merged
Merged
Conversation
provision_participant_range held the participant row lock in one transaction around the whole CMS launch. A pack that declares a feature artifact makes the launch wait for the acquisition launcher, which refuses to run inside a transaction because the launcher cannot see an uncommitted claim. Every CTF participant range for such a pack was rejected at plan time. Commit the #942 claim (range_status="provisioning") and capacity draw under the lock first, launch outside any transaction, then record the instance id. A failed launch returns the draw and restores the prior status so a retry can claim again, matching how spares and recovery already launch. Refs #2479.
Owner
Author
|
Hold: validating live on a GCP tenant before merge. |
…ock baseline Return the registered user from the claim so the launch keeps its non-null type, and assert the outside-transaction launch in the existing success test instead of adding new first-party patch targets (ADR-019-R1).
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
provision_participant_rangeheld the participant row lock (transaction.atomic()+select_for_update()) across the entirecms_create_rangelaunch. When a pack declares a feature artifact (#2479), the launch plan callsawait_ready. By design,await_readyrefuses to run inside a transaction, because the acquisition launcher cannot see an uncommitted claim. As a result, every CTF participant range for such a pack was rejected:Mission Control launches, spares and recovery do not hit this: they already launch outside a transaction.
Change
_claim_for_provisioningholds the row lock only for the already-assigned guard, the PLAT-201 capacity draw and the claim write (range_status="provisioning"), then commits. The existing ctf: scheduler spin-up heartbeat + single-runner election on multi-node portal #942 guard already treats that status as claimed, so concurrent manual and scheduled provisioning still cannot double-assign.range_status, so the retry wrapper can claim again.Verification
tests/ctf/test_services/test_range.py: a new test asserts the launch runs at savepoint depth 0 with the claim already visible. The CMS-failure test now asserts the claim is released.test_range.py,test_capacity_draw_wiring.py, and the provision-filtered API/spares tests pass.claude-codefeature on a GCP tenant; live re-validation follows.Refs #2479