Pipeline: only cancel dependent steps on failure, not all steps#16299
Open
Pipeline: only cancel dependent steps on failure, not all steps#16299
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 16299Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 16299" |
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Aspire hosting pipeline execution behavior so that a failing step no longer cancels all concurrently running steps; instead, only steps that depend on the failed step are prevented from running, while independent steps continue to completion (user-initiated cancellation still flows through the original pipeline context token).
Changes:
- Removed the shared “cancel-all”
CancellationTokenSourcebehavior from the pipeline’s Task-DAG executor. - Kept dependency-based blocking by faulting each step’s completion task so dependent steps don’t execute when prerequisites fail.
- Added tests covering sibling-failure scenarios to ensure independent steps still run and are not implicitly canceled.
Show a summary per file
| File | Description |
|---|---|
| src/Aspire.Hosting/Pipelines/DistributedApplicationPipeline.cs | Removes failure-driven global cancellation in step DAG execution while preserving dependency-based blocking. |
| tests/Aspire.Hosting.Tests/Pipelines/DistributedApplicationPipelineTests.cs | Adds coverage ensuring independent steps continue and are not canceled when a sibling step fails. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 0
When a pipeline step fails, stop cancelling all other running steps via the shared CancellationTokenSource. Instead, let the dependency graph handle it — dependent steps already check their deps and won't run if a dependency faulted. Independent steps continue to completion. This follows the industry standard (GitHub Actions, Azure DevOps, Terraform) where only dependent jobs are blocked on failure. Previously, a container build failure would cancel Azure provisioning mid-authentication, producing misleading DefaultAzureCredential errors that buried the actual root cause. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
372a560 to
14929a8
Compare
Contributor
|
🎬 CLI E2E Test Recordings — 72 recordings uploaded (commit View recordings
📹 Recordings uploaded automatically from CI run #24609589983 |
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.
Description
When any pipeline step fails, the pipeline was cancelling all other running steps via a shared
CancellationTokenSource. This caused independent steps (like Azure provisioning) to fail with misleading errors when an unrelated step (like a container build) failed first.This change removes the cancel-all behavior so that only dependent steps are blocked when a dependency fails. Independent steps continue to completion, matching the industry standard (GitHub Actions, Azure DevOps, Terraform). User-initiated cancellation (Ctrl+C) still works via the original context cancellation token.
The
linkedCtswrapper was also removed as dead code since step failures no longer cancel it.Fixes #16232
Checklist
<remarks />and<code />elements on your triple slash comments?aspire.devissue: