Context
Surfaced by adversarial code review on PR #48 (story 9-9, Edge Case Hunter, finding D7).
Concern
.github/workflows/deploy.yml uses concurrency: { group: deploy-edge-functions-production, cancel-in-progress: false } so concurrent runs queue rather than cancel. Under a push-storm scenario (e.g., a script-driven series of small fixes, a rebase-and-force-push cycle, or rapid workflow_dispatch invocations), runs queue serially with no cap. Each run takes ~2 min × 6 functions; a production environment review may sit blocked, and the queue silently grows.
The cancel-in-progress: false choice was intentional to keep partial deploys atomic — cancelling mid-loop would leave production in a half-deployed state where some functions ride a new revision and others ride the old.
Tradeoff
- Current: safe partial-deploy semantics; bad behavior under storm
- Alternative:
cancel-in-progress: true for Edge-Function-only runs (the latest commit is what should land); migrations are gated manually anyway
Suggested fix
Switch to cancel-in-progress: true if observed; or add a queue-length cap via a custom cancellation step. For now, monitor — the decision should be data-driven, not speculative.
Files
.github/workflows/deploy.yml:29-31
Pull request: #48
Context
Surfaced by adversarial code review on PR #48 (story 9-9, Edge Case Hunter, finding D7).
Concern
.github/workflows/deploy.ymlusesconcurrency: { group: deploy-edge-functions-production, cancel-in-progress: false }so concurrent runs queue rather than cancel. Under a push-storm scenario (e.g., a script-driven series of small fixes, a rebase-and-force-push cycle, or rapidworkflow_dispatchinvocations), runs queue serially with no cap. Each run takes ~2 min × 6 functions; aproductionenvironment review may sit blocked, and the queue silently grows.The
cancel-in-progress: falsechoice was intentional to keep partial deploys atomic — cancelling mid-loop would leave production in a half-deployed state where some functions ride a new revision and others ride the old.Tradeoff
cancel-in-progress: truefor Edge-Function-only runs (the latest commit is what should land); migrations are gated manually anywaySuggested fix
Switch to
cancel-in-progress: trueif observed; or add a queue-length cap via a custom cancellation step. For now, monitor — the decision should be data-driven, not speculative.Files
.github/workflows/deploy.yml:29-31Pull request: #48