BUG: Race condition between manual deploy and webhook deploy on same app #38

New Issue

clawbot · 2026-02-16T06:56:33+01:00

clawbot commented

2026-02-16 06:56:33 +01:00

Severity: MEDIUM

File: `internal/service/deploy/deploy.go` lines ~220-240, `internal/handlers/app.go` HandleAppDeploy, `internal/service/webhook/webhook.go` triggerDeployment

Description

The per-app deployment lock (tryLockApp) correctly prevents concurrent deploys for the same app. However, when a deploy is rejected with ErrDeploymentInProgress:

In HandleAppDeploy (manual deploy): The error is logged but the user is immediately redirected to the deployments page. The user sees no indication that the deploy was rejected — it looks like it was accepted.
In triggerDeployment (webhook): The error is logged but the webhook event is never marked as processed = true, and no retry mechanism exists. The deployment is silently lost.

Suggested Fix

For manual deploys, redirect with an error query param: ?error=deployment_in_progress
For webhook-triggered deploys, either:
- Queue the webhook event and retry after the current deploy finishes
- Mark the event as processed with a note that it was skipped due to concurrent deploy
Consider adding a skipped status for webhook events

## Severity: MEDIUM ## File: `internal/service/deploy/deploy.go` lines ~220-240, `internal/handlers/app.go` HandleAppDeploy, `internal/service/webhook/webhook.go` triggerDeployment ## Description The per-app deployment lock (`tryLockApp`) correctly prevents concurrent deploys for the same app. However, when a deploy is rejected with `ErrDeploymentInProgress`: 1. **In `HandleAppDeploy` (manual deploy)**: The error is logged but the user is immediately redirected to the deployments page. The user sees no indication that the deploy was rejected — it looks like it was accepted. 2. **In `triggerDeployment` (webhook)**: The error is logged but the webhook event is never marked as `processed = true`, and no retry mechanism exists. The deployment is silently lost. ## Suggested Fix 1. For manual deploys, redirect with an error query param: `?error=deployment_in_progress` 2. For webhook-triggered deploys, either: - Queue the webhook event and retry after the current deploy finishes - Mark the event as processed with a note that it was skipped due to concurrent deploy 3. Consider adding a `skipped` status for webhook events

sneak commented

2026-02-16 07:06:57 +01:00

webhook-triggered deploys should cancel the deploy in progress, and start a new one. make me a PR

clawbot referenced a pull request that will close this issue

2026-02-16 07:12:34 +01:00

fix: cancel in-progress deploy when webhook triggers new deploy (closes #38) #52

clawbot referenced a pull request that will close this issue

2026-02-16 07:13:42 +01:00

fix: cancel in-progress deploy on new webhook trigger (closes #38) #53

sneak closed this issue

2026-02-16 09:06:41 +01:00

sneak referenced this issue from a commit