Skip to content

fix(controller): stop starting the next stage after a cancel command#6979

Open
Ahmad-Faraj wants to merge 2 commits into
pipe-cd:masterfrom
Ahmad-Faraj:fix/scheduler-cancel-race
Open

fix(controller): stop starting the next stage after a cancel command#6979
Ahmad-Faraj wants to merge 2 commits into
pipe-cd:masterfrom
Ahmad-Faraj:fix/scheduler-cancel-race

Conversation

@Ahmad-Faraj

Copy link
Copy Markdown

What this PR does:

A cancel that lands while a stage is finishing can be ignored, the stage still reports success and the scheduler moves on. The next iteration then receives nil from the closed cancelledCh and abandons the stage it just started while rollback begins. This makes a received cancel end the deployment even when the stage reported success, and treats a nil receive as a cancellation. Same fix in piped and pipedv1.

Why we need it:

A cancelled deployment should not keep executing stages, and rollback should not run in parallel with a forward stage.

Which issue(s) this PR fixes:

Fixes #6978

Does this PR introduce a user-facing change?:

  • How are users affected by this change: cancelling now reliably stops the deployment after the current stage.
  • Is this breaking change: no
  • How to migrate (if breaking change): n/a

When a cancel arrives while a stage is finishing, the stage can still
report success and the scheduler continues to the next stage. The next
select then receives nil from the closed cancelledCh and falls through
without cancelling or waiting for the just-started stage, leaving it
running while rollback begins. Make a received cancel command terminate
the deployment even when the stage reported success, and treat a nil
receive as a cancellation.

Signed-off-by: Ahmad Faraj <ahmedfrag4040@gmail.com>
Copilot AI review requested due to automatic review settings July 4, 2026 20:37
@Ahmad-Faraj Ahmad-Faraj requested review from a team as code owners July 4, 2026 20:37

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR improves cancellation handling in the Piped controllers’ schedulers so that a user cancel reliably stops stage progression and avoids leaving a forward stage running while rollback begins.

Changes:

  • Ensure a received cancel ends the deployment even if the current stage reports STAGE_SUCCESS.
  • Treat receives from a closed cancelledCh as a cancellation signal by always cancelling/waiting for the current stage.
  • Apply the same scheduler behavior fix in both piped and pipedv1.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File Description
pkg/app/pipedv1/controller/scheduler.go Adjusts cancel-channel handling and cancellation precedence after stage completion.
pkg/app/piped/controller/scheduler.go Mirrors the same cancel precedence and closed-channel handling changes for legacy piped.

Comment on lines +389 to +395
// A received cancel command wins even if the stage finished successfully,
// otherwise the loop would continue to the next stage after the user cancelled.
if cancelCommand != nil {
deploymentStatus = model.DeploymentStatus_DEPLOYMENT_CANCELLED
statusReason = fmt.Sprintf("Cancelled by %s while executing stage %s", cancelCommander, ps.Id)
break
}
Comment on lines +390 to +396
// A received cancel command wins even if the stage finished successfully,
// otherwise the loop would continue to the next stage after the user cancelled.
if cancelCommand != nil {
deploymentStatus = model.DeploymentStatus_DEPLOYMENT_CANCELLED
statusReason = fmt.Sprintf("Cancelled by %s while executing stage %s", cancelCommander, ps.Id)
break
}
Comment on lines 372 to +380
case cmd := <-s.cancelledCh:
// A nil command means the channel was closed after delivering
// a cancel command, so treat it as a cancellation as well.
if cmd != nil {
cancelCommand = cmd
cancelCommander = cmd.Commander
handler.Cancel()
<-doneCh
}
handler.Cancel()
<-doneCh
…age completes

The select can pick doneCh while a cancel command is already buffered,
which would let the next stage start before the cancel is observed.
Drain the channel non-blocking after the stage completes.

Signed-off-by: Ahmad Faraj <ahmedfrag4040@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cancelling a deployment right as a stage finishes can leave the next stage running

2 participants