fix: Remove remaining blocking wait_for_operation calls #990
+647
−45
Conversation
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
This PR removes the last two blocking wait_for_operation calls that were causing gunicorn workers to be blocked for extended periods: 1. delete_expired_instances() - VM deletion is now fire-and-forget 2. start_test() - VM creation is now optimistic (recorded immediately) These blocking calls were causing 504 timeouts on webhook deliveries because GitHub has a 10-second webhook timeout. When cron jobs were running wait_for_operation (which can take up to 30 minutes), all gunicorn workers could become blocked, causing webhook requests to queue and exceed the timeout. Changes: - delete_expired_instances: Remove blocking wait, log operation initiation - start_test: Check for immediate errors, then record instance optimistically - Tests: Remove unused wait_for_operation mocks from affected tests If VM creation ultimately fails, the test won't report progress and will be cleaned up by the expired instances cron job. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
cfsmp3
requested review from
canihavesomecoffee and
thealphadollar
as code owners
Implements a robust system to ensure GCP VMs are properly deleted: - Add PendingDeletion model to track deletion operations - Add delete_instance_with_tracking() to record pending deletions - Add verify_pending_deletions() to check operation status and retry failures - Add scan_for_orphaned_vms() as final safety net for missed deletions - Integrate verification into start_platforms() cron flow - Update both deletion points to use tracking - Add database migration for pending_deletion table - Add 11 tests for new functionality This prevents orphaned VMs from continuing to incur billing charges when deletion operations fail silently. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
wait_for_operationindelete_expired_instances()(VM deletion now fire-and-forget)wait_for_operationinstart_test()(VM creation now optimistic)Problem
These blocking calls were causing 504 timeouts on webhook deliveries because:
wait_for_operation(which can block for up to 30 minutes), gunicorn workers become blockedHowever, simply making deletions fire-and-forget creates a new problem: if a deletion fails, the VM continues running and incurring charges with no way to detect or recover.
Solution
Part 1: Remove blocking waits (original PR)
delete_expired_instances: Delete VMs without waiting for confirmationstart_test: Check for immediate errors, then record instance optimisticallyPart 2: VM Deletion Tracking System (new)
A robust system to ensure VMs are properly deleted:
PendingDeletionmodeldelete_instance_with_tracking()verify_pending_deletions()scan_for_orphaned_vms()Cron flow (every 10 minutes):
verify_pending_deletions()- Check pending ops from previous runsscan_for_orphaned_vms()- Catch any orphans we misseddelete_expired_instances()- Delete timed-out VMs (with tracking)gcp_instance()- Start new testsThis provides defense in depth: tracked deletions are verified and retried, and the orphan scan catches anything that slips through.
After merging, run the database migration:
This creates the
pending_deletiontable needed for tracking. The migration is safe and non-destructive.No action required before merging - the new code is backwards compatible and will work even before the migration runs (it will just fail to track deletions until the table exists).
Test plan
🤖 Generated with Claude Code