Repository navigation
fix: guard teardown against concurrent Deploy + release SMB locks - #37
Conversation
Two race conditions fixed: - Add a pre-flight check that blocks teardown if Deploy is in_progress, preventing SMB SharingViolation when Deploy is mounting file shares - Sleep 60s after az container delete before wiping file shares so Azure has time to release SMB locks on the shares
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 195cc0ef98
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| RUNNING=$(gh run list \ | ||
| --repo ${{ github.repository }} \ | ||
| --workflow=deploy.yml \ | ||
| --status=in_progress \ |
There was a problem hiding this comment.
If a Deploy has been triggered by the push-to-main workflow but is still queued, pending, requested, or waiting when teardown starts, this filter returns zero because it only asks for in_progress (the gh run list manual documents these as valid --status values alongside in_progress). In that window teardown proceeds, then .github/workflows/deploy.yml lines 121-136 can still run az container create with the Azure File shares mounted, so the teardown either races the share wipe or is undone by a newly created ACI; query all non-terminal deploy statuses or use a shared concurrency group with Deploy.
Useful? React with 👍 / 👎.
1 participant
Problem
Two race conditions in the new
teardownaction discovered immediately after merging #36:mainauto-triggersDeploy, which mounts the file shares via SMB. Ifteardownruns while Deploy is in progress,az storage file delete-batchhits aSharingViolationand fails.az container delete, Azure takes ~60s to fully release SMB locks. Wiping shares immediately after deletion also causesSharingViolation.Fix
gh run list --workflow=deploy.yml --status=in_progressand blocks teardown if a Deploy is running.az container deletebefore attempting to wipe the shares.actions: readpermission soghcan query workflow runs.