Skip to content
MantisDocs

Cancellation

Stop deployments safely when needed.

When to Cancel

Section titled “When to Cancel”

Consider cancellation when:

ScenarioAction
Wrong version deployedCancel immediately
Target issues discoveredCancel and investigate
Deployment taking too longCancel and troubleshoot
Business decision changeCancel if safe
Environment instabilityCancel to protect production

Cancellation Methods

Section titled “Cancellation Methods”

From Deployment Detail

Section titled “From Deployment Detail”
┌─────────────────────────────────────────────────────────────┐
│  Deployment: customer-portal v1.3.0 → Production            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Status: ● In Progress     Progress: 40%                    │
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ ⚠ Cancellation prevents not-yet-started steps         │  │
│  │   4 of 10 targets have completed                      │  │
│  │   Pending/queued steps will be cancelled              │  │
│  │   In-flight commands run to completion (results       │  │
│  │   discarded)                                          │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
│                                             [Cancel]        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Confirmation Dialog

Section titled “Confirmation Dialog”
┌─────────────────────────────────────────────────────────────┐
│  Cancel Deployment?                                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  This will:                                                 │
│  • Cancel all pending and queued steps                      │
│  • Let in-flight commands finish on the target              │
│    (their results are discarded)                            │
│  • Mark deployment as cancelled                             │
│                                                             │
│  Currently running: web-prod-05, web-prod-06                │
│                                                             │
│                        [Keep Running]  [Cancel Deployment]  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

From Dashboard

Section titled “From Dashboard”

Quick cancel from the active deployments list:

┌─────────────────────────────────────────────────────────────┐
│  Active Deployments                                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  customer-portal v1.3.0  ● 40%  [View] [Cancel]             │
│  auth-service v2.0.0     ● 80%  [View] [Cancel]             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

From CLI

Section titled “From CLI”
Terminal window
# Cancel by deployment ID
mantisctl deployment cancel <deployment-id>


# Skip the confirmation prompt (does NOT kill running commands)
mantisctl deployment cancel <deployment-id> --force


# Cancel with a reason (stored with the deployment record)
mantisctl deployment cancel <deployment-id> --reason "Bug discovered in v1.3.0"

Cancellation Behavior

Section titled “Cancellation Behavior”

What Happens on Cancel

Section titled “What Happens on Cancel”

Step States After Cancel

Section titled “Step States After Cancel”
Step StateResult
CompletedRemains completed
RunningContinues to run on the target; result is discarded
QueuedTransitions to cancelled, never starts
PendingTransitions to cancelled, never starts

Running Command Behavior

Section titled “Running Command Behavior”

Running commands cannot be aborted mid-execution. Cancellation does not send any signal to the target process — there is no SIGTERM/SIGKILL escalation.

When a target already has a command running:

  1. No interruption - The command continues to execute on the target until it finishes naturally.
  2. Results discarded - When it completes, its result is ignored rather than recorded against the cancelled deployment.
  3. Only not-yet-started steps are stopped - Pending and queued steps transition to cancelled so they never dispatch.

Cancellation therefore prevents further work from starting, but any command already in flight runs to completion on the target.

Partial Deployment State

Section titled “Partial Deployment State”

After cancellation, some targets may have the new version:

┌─────────────────────────────────────────────────────────────┐
│  Deployment: Cancelled                                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Final State:                                               │
│  ┌────────────────┬──────────┬─────────────────────────┐   │
│  │ Target         │ Status   │ Version                 │   │
│  ├────────────────┼──────────┼─────────────────────────┤   │
│  │ web-prod-01    │ ✓ Done   │ v1.3.0 (new)            │   │
│  │ web-prod-02    │ ✓ Done   │ v1.3.0 (new)            │   │
│  │ web-prod-03    │ ⊘ Cancel │ v1.2.0 (old)            │   │
│  │ web-prod-04    │ - Skip   │ v1.2.0 (old)            │   │
│  └────────────────┴──────────┴─────────────────────────┘   │
│                                                             │
│  ⚠ Environment is in mixed state                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Recovery After Cancellation

Section titled “Recovery After Cancellation”

Resume Deployment

Section titled “Resume Deployment”

Create a new deployment targeting only the incomplete targets:

Terminal window
# Deploy to remaining targets
mantisctl deployment create --solution-id customer-portal \
  --source-version 1.3.0 \
  --target web-prod-03 \
  --target web-prod-04

Rollback Completed Targets

Section titled “Rollback Completed Targets”

Return completed targets to the previous version:

Terminal window
# Rollback specific targets to the previous version
mantisctl deployment create --solution-id customer-portal \
  --source-version 1.2.0 \
  --target web-prod-01 \
  --target web-prod-02

Full Re-Deploy

Section titled “Full Re-Deploy”

Start a fresh deployment to all targets:

Terminal window
mantisctl deployment create --solution-id customer-portal \
  --source-version 1.3.0 \
  --environment-id production

Cancellation Restrictions

Section titled “Cancellation Restrictions”

Cannot Cancel When

Section titled “Cannot Cancel When”
ScenarioReason
Deployment completedAlready finished
Deployment failedAlready stopped
Already cancelledCan’t cancel twice

The --force Flag

Section titled “The --force Flag”

The CLI --force flag only skips the confirmation prompt so the cancel can run non-interactively (for example, in scripts):

Terminal window
mantisctl deployment cancel <deployment-id> --force

It does not forcibly terminate work on the target. A command already running on a target still runs to completion regardless of --force; cancellation only prevents not-yet-started steps from dispatching.

Cancellation Record

Section titled “Cancellation Record”

Cancellation details are stored with the deployment record. When a --reason is supplied it is saved alongside the deployment and visible on the deployment detail view. No separate audit log entry is created for cancellations.

Preventing Unnecessary Cancellations

Section titled “Preventing Unnecessary Cancellations”

Pre-Deployment Checks

Section titled “Pre-Deployment Checks”
  • Correct version selected
  • Correct environment/targets
  • Team notified
  • Rollback plan ready

During Deployment

Section titled “During Deployment”
  • Monitor progress actively
  • Watch for early failures
  • Have team available

Use Staged Rollouts

Section titled “Use Staged Rollouts”

Deploy to small batches first:

Phase 1: Canary (1 target)     - Verify
Phase 2: Small batch (10%)     - Validate
Phase 3: Remaining (90%)       - Complete

Best Practices

Section titled “Best Practices”

1. Cancel Early

Section titled “1. Cancel Early”

If issues are detected:

  • Cancel immediately
  • Fewer targets affected
  • Easier recovery

2. Document Reason

Section titled “2. Document Reason”

Record why cancellation occurred:

Terminal window
mantisctl deployment cancel <id> --reason "Bug discovered in v1.3.0"

3. Plan Recovery

Section titled “3. Plan Recovery”

Before cancelling, consider:

  • Which targets have the new version?
  • What’s the rollback plan?
  • Who needs to be notified?

4. Communicate

Section titled “4. Communicate”

Inform stakeholders:

  • What was cancelled
  • Current system state
  • Next steps

Troubleshooting

Section titled “Troubleshooting”

Cancel Button Not Working

Section titled “Cancel Button Not Working”

Cause: Deployment may have already completed

Solution: Refresh page to get current status

A Command Keeps Running After Cancel

Section titled “A Command Keeps Running After Cancel”

Cause: Expected behavior - a command already in flight cannot be aborted and runs to completion on the target. Its result is discarded.

Solution: Wait for it to finish naturally; no action is needed for the deployment, which is already marked cancelled.

Mixed State After Cancel

Section titled “Mixed State After Cancel”

Cause: Expected behavior - some targets completed

Solution: Deploy to remaining targets or rollback completed ones

Cannot Resume After Cancel

Section titled “Cannot Resume After Cancel”

Cause: Original deployment cannot be modified

Solution: Create new deployment targeting specific targets

Next Steps

Section titled “Next Steps”