fix: include deploy trigger in build dedupe key to prevent dropped deploys#218
Merged
Conversation
…ploys The resolve/build queue dedupe key was derived only from a build configuration fingerprint, not the commit being deployed. When two deploys of the same build were triggered close together (e.g. two pushes to a tracked branch landing within the queue's dedupe window) both produced an identical key. The build job is keyed by jobId, so a duplicate enqueue is a no-op: the second deploy was silently coalesced into the first and the newer commit never built, with no error and no log line. Append a per-trigger ref to the resolve dedupe id and build jobId: the pushed head commit for branch pushes, or a unique run id for manual redeploys. Distinct triggers now get distinct keys, while genuine duplicates of the same trigger (such as a redelivered webhook) still coalesce. Thread the ref from the resolve step into the build step so both queue layers agree, and log when an enqueue is deduped so the drop is observable.
The comment-triggered redeploy (#REDEPLOY) and the override-triggered redeploy already generate a unique run id but passed it only as runUUID, not as the dedupe trigger. As a result they kept the commit-agnostic dedupe key and two redeploys landing close together could still be silently coalesced into one. Pass the existing run id as triggerRef on both paths so each explicit redeploy gets a distinct dedupe key. Also add a test that locks in the resolve-step to build-step triggerRef forwarding, the invariant that keeps both queue layers on the same dedupe identity.
3 tasks
vigneshrajsb
added a commit
that referenced
this pull request
Jun 23, 2026
…rent builds (#219) * fix: pass triggerRef in PR synchronize handler to coalesce with push event When a user pushes to a PR branch, GitHub fires both a push event and a pull_request synchronize event for the same commit. PR #218 added triggerRef (the commit SHA) to the push handler's enqueueResolveAndDeployBuild call so that back-to-back distinct commits are not silently coalesced. However, the synchronize handler was not updated, so it still enqueues with no triggerRef. The two events now produce different dedupe keys: push: resolve:<buildId>:<fingerprint>:<commitSha> sync: resolve:<buildId>:<fingerprint> Both jobs run concurrently, race for runUUID ownership, and if the losing run encounters an error it patches the build status to ERROR even though all services are healthy. Fix: pass the same branchSha as triggerRef in the synchronize handler so both events produce identical dedupe keys and coalesce to a single resolveAndDeployBuild run. * docs: correct inline comment on synchronize triggerRef to not overstate coalescing The previous comment claimed push and synchronize produce the same dedupe key and coalesce, which is only true when the push path omits githubRepositoryId (e.g. the failed-deploy rebuild path). In the normal case, push passes githubRepositoryId so its fingerprint differs from the synchronize path even with matching triggerRef. Update the comment to accurately describe the fix as preventing back-to-back synchronize events for distinct commits from collapsing. * fix: remove isSynchronized deploy handler — redundant with push handler The pull_request synchronize handler added in PR #205 enqueues resolveAndDeployBuild for every PR push, but the push event handler already covers the same work. deployable.defaultBranchName stores the literal yaml value (e.g. "@Branch", "main"), never the resolved PR branch name, so shouldBuild is always true for PR environments — the push handler fires for every service without exception. Having both handlers enqueue for the same commit causes two concurrent resolveAndDeployBuild runs that race for runUUID ownership. If the losing run hits any error, recordBuildFailure force-patches runUUID and writes ERROR status even though the winning run's services are healthy. Remove the synchronize block and its now-unused isSynchronized variable. Remove the corresponding test that asserted the redundant enqueue.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
The resolve/build queue dedupe key was derived only from a build configuration fingerprint, not the commit being deployed. When two deploys of the same build were triggered close together — for example, two pushes to a tracked branch landing within the queue's dedupe window — both produced an identical key.
The build job is keyed by
jobId, and a duplicatejobIdenqueue is a no-op. So the second deploy was silently coalesced into the first: the newer commit never built, with no error and no log line. The only visible symptom is a missing deploy and a stale release.Fix
jobId:Tests