sec(ci): gate terraform force-unlock behind explicit input (closes #438) - #818
Conversation
|
@coderabbitai review |
|
Important Review skippedNo new commits to review since the last review. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThe workflow now clears Terraform S3 state locks only when explicitly requested through ChangesOperator-triggered Terraform state lock recovery
Estimated code review effort: 2 (Simple) | ~12 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
✅ Actions performedReview triggered.
|
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
Rate Limit Exceeded
|
|
@coderabbitai full review Generated by Claude Code |
|
🧠 Learnings used✅ Action performedFull review finished. |
|
@coderabbitai full review |
✅ Action performedFull review finished. |
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-aws-fargate.yml:
- Around line 117-132: The workflow has an automatic failure-path unlock
mechanism that unconditionally removes the Terraform state lock on any failed or
cancelled run, which creates a race condition where one failing concurrent run
can delete another healthy run's active lock, causing state corruption. Either
remove the automatic failure-path unlock mechanism entirely and rely solely on
the operator-triggered clear_stale_lock step (which requires explicit
input.clear_stale_lock == true), or modify the failure-path unlock to include
ownership awareness by adding a unique identifier or token that tracks which run
created the lock before allowing removal. The safest approach is to delete the
automatic failure cleanup step and require manual operator intervention via the
clear_stale_lock input flag.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 56c13b0f-5208-4309-86a4-9983e17993f6
📒 Files selected for processing (2)
.github/workflows/deploy-aws-fargate.ymlrunbooks/terraform-stuck-lock.md
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
|
Merge-prep: rebased onto origin/main (27fdb06), no conflicts. Non-Go PR; go vet on internal/... clean. @coderabbitai full review |
Unconditionally deleting the S3 state lock before every terraform init allowed concurrent dispatch runs to race and corrupt state. Remove the automatic deletion and replace it with a gated step that only runs when the operator explicitly sets clear_stale_lock=true on workflow_dispatch. The existing failure/cancellation cleanup step is unchanged. Add runbooks/terraform-stuck-lock.md with diagnosis and recovery steps.
…k.md markdownlint MD040 requires fenced code blocks to specify a language. The error-output block at line 7 had a bare ``` opener; add "text" tag.
The "Release state lock on failure" step deleted the S3 tflock on any failed/cancelled run. A run that fails because it could not acquire the lock would delete the lock a concurrent run is still actively holding, re-introducing the state-corruption race this PR aims to close. Remove the automatic failure-path unlock. Terraform already releases its own lock on a clean apply error; a lock surviving a run means the run died abnormally, which requires operator confirmation via clear_stale_lock before clearing. Update the runbook accordingly.
|
@coderabbitai review |
✅ Action performedReview finished.
|
Summary
deploy-aws-fargate.ymlworkflow unconditionally deleted the S3 Terraform state lock before everyterraform init, allowing concurrent dispatch runs to race and corrupt state (issue sec(ci): deploy-aws-fargate.yml unconditionally deletes Terraform state-lock file at init time #438).inputs.clear_stale_lock == true(aworkflow_dispatch-only boolean input, defaultfalse). The existingif: failure() || cancelled()cleanup step is unchanged.runbooks/terraform-stuck-lock.mdexplaining when/how to use the escape hatch and why unconditional clearing is unsafe.Test plan
workflow_dispatchrun (withoutclear_stale_lock) no longer deletes the lock file at init time.clear_stale_lock=trueexecutes the new step and removes the lock object.Release state lock on failurestep still fires on job failure/cancellation.python3 -c "import yaml; yaml.safe_load(open('.github/workflows/deploy-aws-fargate.yml'))"passes.Summary by CodeRabbit
New Features
Documentation
Operational Safety