Defer explicit-start DCP registration#17825
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>
|
🚀 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" |
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. |
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
|
|
/backport to release/13.4 |
|
Started backporting to |
karolz-ms
left a comment
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>
|
/backport to release/13.4 |
|
Started backporting to |
|
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.
|
|
❓ CLI E2E Tests unknown — 110 passed, 0 failed, 2 unknown (commit View all recordings
📹 Recordings uploaded automatically from CI run #26837904558 |
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>
|
Pull request created: #1194
|
|
📝 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. |
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?