Repository navigation
Conversation
- Add "queued" status to deploymentStatus, applicationStatus enums - Create deployment records at enqueue time for immediate UI visibility - Show blue dot for queued deployments, loading state on deploy buttons - Cancel queued deployments cleanly with proper DB + queue cleanup - Extract shared helpers: resolveQueuedDeployment, enqueueDeployment - Use millisecond-precision timestamps in log filenames to prevent collisions - Fix preview deployment grouping in in-memory queue - Add per-app try/catch in GitHub webhook handler
…quests Atomic claim in resolveQueuedDeployment only transitions deployments still in queued status, so a cancelled record cannot be set back to running. Move initCancelDeployments before server.listen so no HTTP requests can arrive during stale-record cleanup.
imrja8
force-pushed
the
feat/visual-deployment-queue
branch
from
September 11, 2026 17:43
6885306 to
337f47b
Compare
- Atomic WHERE status = 'queued' claim prevents cancelled jobs from running - initCancelDeployments before server.listen prevents startup cancelling live requests - getActiveDeploymentStatus helper preserves queued/running status when deployments remain - Per-service mutex prevents enqueue/cancel interleaving Extracted shared helpers to eliminate 40+ lines of duplication across services.
…eployments - Add priority ordering to getActiveDeploymentStatus (running > queued) - Recompute aggregate status after startup cleanup instead of forcing idle - Update DB records and recompute status in cleanAllDeploymentQueue - Add status recomputation to per-service queue cleanup functions - Centralize terminal status updates in processDeploymentJob with service lock - Create updateServiceStatusFromActiveDeployments helper to eliminate duplication - Remove dead code: unreachable if (!deploymentId) blocks - Fix unused imports and formatting for biome compliance
Collaborator
Author
|
Closing this since it only covers self-hosted. Cloud uses a separate Inngest pipeline and needs its own queue visibility work. I’m closing this in favor of PR #4146 effort, will work with author. |
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
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.
What is this PR about?
Follow up to #4774, which I closed after it grew beyond the original intent. I decided to split it into two focused PRs.
The problem
When a user triggers multiple deployments quickly (rapid GitHub pushes, clicking deploy while one is already running), the system queues them internally but shows nothing in the UI. The user only sees the currently running deployment. There is no indication that others are waiting. This leads to confusion, users clicking deploy again thinking it did not work, and no way to know what the system is actually doing behind the scenes.
What this PR does
Makes the queue visible. After this change:
How it works
The key change is that deployment database records are now created at enqueue time (with
status: "queued") instead of when the worker starts executing. This is what makes them show up in the list. When the worker picks up a job, the record transitions from queued to running.Three enqueue helpers (
enqueueApplicationDeployment,enqueueComposeDeployment,enqueuePreviewDeployment) replace all directmyQueue.addcalls and handle the record creation, status updates, and error recovery in one place.Log filenames now use millisecond precision to prevent collisions when multiple records are created in quick succession.
On server restart, any deployments left in a queued state are cleaned up since the in memory queue no longer has those jobs.
What is NOT in this PR
Individual deployment kill behavior and PID based process cancellation, that is Part 2. The global deployments dashboard page is not updated as it was outside the original file scope.
Existing behavior
Nothing changes for the existing flow. When a deployment is triggered normally, it goes through the same code path as before. The queued state is purely additive.
Checklist
canarybranch.Issues related (if applicable)
Supersedes #4774
Screenshots
Project Dashboard [Running, Queued, Cancelled (idle) states] - Click to OPEN/CLOSE
1. Running state: On going deployment state for service

2. Queued state: Pending deployment state for service

3. Cancelled (Idle) state: Canclled deployment (before build) state for service

Button Loading (Running | Queued) States - Click to OPEN/CLOSE
Running state Deploy/Redeploy button (Pre-existing: loading state to prevent multiple redeploys while running)

Queued state Deploy/Redeploy button (Added in this PR: loading state extends to queued status to prevent multiple rapid enqueues, unless triggered via webhook)

The PR appears safe to merge; the previously reported queue races and aggregate-status problems are resolved in the current code.
Summary
Reviews (5) · Last reviewed commit: "fix: close 4 race conditions in queued d..."