Repository navigation
Conversation
Port the service label tests onto the shared inspect and update mocks, and reset the rollout wait mock between tests so a rejection set by one test does not leak into the next.
Swarm's updater exits early when no existing task needs replacing and never writes UpdateStatus, so deploying a stopped or scaled-to-zero service waited until the timeout and reported a working deploy as failed.
The derived budget ignores image pull time, container start and the health-check start period, so a two-minute floor reported slow but healthy rollouts as failed while Swarm was still converging.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+176
to
+184
| const isExpectedRollback = | ||
| state?.startsWith("rollback_") && | ||
| Boolean( | ||
| await getLatestTaskFailure( | ||
| docker, | ||
| service.id, | ||
| options.expectedForceUpdate, | ||
| ), | ||
| ); |
Contributor
There was a problem hiding this comment.
If the first poll sees an automatic rollback and listTasks fails, isExpectedRollback becomes false. Rollback restores the old ForceUpdate, so the function reports “superseded by another operation” instead of the rollback. Users still see a failed deployment, but get the wrong explanation.
Keep task lookup optional for error details rather than using its result to decide whether the rollback belongs to this deployment.
A rollback restores the previous ForceUpdate, so it was only matched to this update through a failed task. When the lookup failed or the new task exited cleanly, the rollback was reported as a superseding operation.
This branch has not been deployed
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.
Summary
Rebase of #5218 by @bestmaa onto current
canary, with the original commits and authorship preserved, plus three follow-up commits. Fixes #3987.Today
mechanizeDockerContainercallsservice.updateand the deployment is marked done immediately. With Dokploy's defaultUpdateConfig(start-first,FailureAction: rollback), a new task that dies inside Swarm's monitor window is rolled back to the previous spec, the old image keeps running, and the deployment log still shows success.Commits
fix(swarm): report failed service rolloutsandfix(swarm): correlate rollout status updates— the two commits from fix(swarm): report failed service rollouts #5218, cherry-picked. The only conflict was inbuilders/index.ts, where canary added the service-level label carry-over from Docker-image apps: any deploy (webhook or API) rewrites the Swarm service spec and drops the app's traefik.* labels → all domains 404 #5453; both behaviours are kept (Labels: inspect.Spec?.Labels ?? {}is passed to the newservice.updatecall).test(swarm): keep label carry-over tests after rebase— ports canary's two label tests onto the PR's mocks, and resets the wait mock between tests so a rejected wait cannot leak into later tests.fix(swarm): skip the rollout wait when no task was running— Swarm's updater exits early when no existing task needs replacing and never writesUpdateStatus. A deploy of a stopped or scaled-to-zero service therefore waited until the timeout and was reported as failed although the new tasks started. The tasks with desired staterunningare listed before the update; if there are none, the update is applied without waiting. A listing error falls back to waiting.fix(swarm): allow a rollout ten minutes before timing out— the derived budget ignores image pull time, container start and the health-check start period, so the two-minute floor reported slow but healthy rollouts as failed while Swarm was still converging.Known limitation, unchanged from the original PR: a service whose tasks stay pending because no node can place them waits until the timeout.
Tests
swarm-update(10),mechanizeDockerContainer(14, including the three new cases for the no-running-task path),application.command,preview-build-server,provider-status: pass. Full suite: 1511 passed.tsc --noEmitforserveranddokploy: pass. Biome: clean.The PR appears safe to merge, with a non-blocking issue in how it explains some automatic rollbacks.
Summary
The PR waits for existing Swarm service rollouts before marking deployments successful.
Acknowledged behavior:
mjafartpintentionally skips waiting when no previous task needs replacing because Swarm may not writeUpdateStatus.mjafartpacknowledges that tasks with no eligible node wait until timeout.Reviews (1) · Last reviewed commit: "fix(swarm): allow a rollout ten minutes ..." · Reviewed by Greptile