Repository navigation
Defer explicit-start DCP registration - #17825
Merged
Merged
Conversation
Avoid evaluating execution configuration callbacks for session-scoped explicit-start resources until they are manually started. Persistent explicit-start resources are still registered eagerly, but manual start now patches the existing DCP object instead of recreating it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17825Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17825" |
David Negstad (danegsta)
marked this pull request as ready for review
June 2, 2026 05:02
David Negstad (danegsta)
requested a review
from Mitch Denny (mitchdenny)
as a code owner
June 2, 2026 05:02
David Negstad (danegsta)
requested review from
James Newton-King (JamesNK),
David Fowler (davidfowl) and
Karol Zadora-Przylecki (karolz-ms)
as code owners
June 2, 2026 05:02
Contributor
There was a problem hiding this comment.
Pull request overview
Defers DCP object creation for session-scoped resources marked with WithExplicitStart() so that execution configuration callbacks (args/env, etc.) aren’t evaluated during AppHost/dashboard startup, while keeping persistent explicit-start resources created immediately and starting them via a Spec.Start=true patch to avoid re-running callbacks.
Changes:
- Defer DCP registration/creation for explicit-start non-persistent containers/executables until manual start.
- Start already-created explicit-start persistent resources by patching
Spec.Start=trueinstead of delete/recreate. - Expand test coverage and add Stress playground interaction examples to validate callback deferral vs persistence behavior.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| tests/Aspire.Hosting.Tests/Dcp/TestKubernetesService.cs | Extends the test Kubernetes patch behavior to honor Spec.Start updates for executables/containers. |
| tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs | Updates and adds tests covering deferred creation for session-scoped explicit-start resources and non-reevaluation for persistent explicit-start start. |
| src/Aspire.Hosting/Dcp/ExecutableCreator.cs | Uses the new utility to decide whether explicit-start executables should be created immediately or deferred. |
| src/Aspire.Hosting/Dcp/DcpModelUtilities.cs | Adds ShouldDeferCreateForExplicitStart helper encapsulating the deferral decision logic. |
| src/Aspire.Hosting/Dcp/DcpExecutor.cs | Adds a “patch start” path for already-created delayed-start resources and refactors patching into a helper method. |
| src/Aspire.Hosting/Dcp/ContainerCreator.cs | Uses the new utility to decide whether explicit-start containers should be created immediately or deferred. |
| playground/Stress/Stress.AppHost/AppHost.cs | Adds prompt-based Stress examples to validate callback deferral behavior for explicit-start session vs persistent resources. |
Member
Author
PR Testing ReportPR Information
CLI Version Verification
Changes AnalyzedFiles Changed
Change Categories
Test Scenarios ExecutedScenario 1: PR CLI install and version verificationObjective: Install the dogfood CLI for PR #17825 into an isolated temp directory and verify it reports the PR head commit. Steps:
Evidence:
Observations:
Scenario 2: Session-scoped explicit-start executable defers callbackObjective: Verify a session-scoped explicit-start executable does not evaluate a Steps:
Evidence:
Observations:
Scenario 3: Persistent explicit-start executable does not evaluate callback twiceObjective: Verify a persistent explicit-start executable evaluates configuration during AppHost startup registration, then manual start only flips DCP start state without re-running callbacks. Steps:
Evidence:
Observations:
Scenario 4: Container explicit-start parityObjective: Verify the same callback deferral and persistent no-second-evaluation behavior for containers using the same long-running command. Steps:
Evidence:
Observations:
Unhappy-Path CoverageCallback-that-would-fail-at-startupExpected Outcome: AppHost startup succeeds and the resource remains
Persistent repeated start boundaryExpected Outcome: Manual start of an already-created persistent explicit-start resource does not duplicate callback side effects. Both persistent executable and persistent container marker counts remained at one after manual start. Summary
Overall Result✅ PR VERIFIED Recommendations
|
Member
Author
|
/backport to release/13.4 |
Contributor
|
Started backporting to |
Mitch Denny (mitchdenny)
approved these changes
Jun 2, 2026
Karol Zadora-Przylecki (karolz-ms)
requested changes
Jun 2, 2026
Karol Zadora-Przylecki (karolz-ms)
left a comment
Karol Zadora-Przylecki (karolz-ms)
left a comment
Contributor
There was a problem hiding this comment.
Looks good overall but there are a few minor issues worth correcting (or, in one case, considering) before merging.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/backport to release/13.4 |
Contributor
|
Started backporting to |
Karol Zadora-Przylecki (karolz-ms)
approved these changes
Jun 2, 2026
David Negstad (danegsta)
enabled auto-merge (squash)
June 2, 2026 18:10
Contributor
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
Contributor
|
❓ CLI E2E Tests unknown — 110 passed, 0 failed, 2 unknown (commit View all recordings
📹 Recordings uploaded automatically from CI run #26837904558 |
aspire-repo-bot Bot
added a commit
to microsoft/aspire.dev
that referenced
this pull request
Jun 2, 2026
Add a new 'Defer resource start with explicit start' section to resource-lifetimes.mdx explaining how WithExplicitStart() interacts with execution configuration callbacks (WithEnvironment, WithArgs): - Session-scoped explicit-start resources defer DCP registration until manual start, so callbacks run only when the user starts the resource from the dashboard. - Persistent explicit-start resources are registered immediately (to detect existing instances), but use a Spec.Start patch on manual start so callbacks are not re-evaluated a second time. Documents microsoft/aspire#17825. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Pull request created: #1194
|
Contributor
|
📝 Documentation has been drafted in microsoft/aspire.dev#1194 targeting Added a new "Defer resource start with explicit start" section to File modified:
Note This draft PR needs human review before merging. |
4 of 8 tasks
1 task done
James Newton-King (JamesNK)
added a commit
that referenced
this pull request
Jun 9, 2026
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
Session-scoped resources marked with
WithExplicitStart()should not evaluate execution configuration callbacks during AppHost/dashboard startup. Those callbacks can prompt for user input or contribute arguments, environment variables, certificates, and other start-time configuration before the user has explicitly started the resource.This change defers DCP registration for session-scoped explicit-start containers and executables until manual start. Persistent explicit-start resources are still registered immediately so DCP can evaluate the lifecycle key and discover existing instances, but manual start now patches the existing DCP resource to
Spec.Start = trueinstead of deleting and recreating it, avoiding a second callback prompt.User-facing usage
The Stress playground now includes prompt-based examples for validating this behavior:
Manual session-scoped resources should prompt only when manually started. Persistent resources prompt during startup because they must be registered with DCP immediately, and should not prompt again when manually started.
Validation:
Fixes: #17813
Checklist
<remarks />and<code />elements on your triple slash comments?