Expose IInteractionService to polyglot app hosts

[sebastienros]

Description

Aspire's IInteractionService (prompts, message boxes, notifications, and dynamic inputs) was only reachable from C# app hosts. Polyglot app hosts (TypeScript, Python, Go, Java, Rust) had no way to drive user interactions even though other services are already exposed through the ATS callback-service-provider surface. This PR brings the interaction service to polyglot app hosts.

The core challenge is that the natural way to model interaction inputs as DTOs breaks down for inputs that carry callbacks (dynamic option loading, dialog validation): delegates are not serializable across the ATS/JSON-RPC boundary. Modeling them as DTO fields produces a runtime serialization crash.

Approach

The work was done in the order the design required:

• Expose ServiceProvider from ExecuteCommandContext so polyglot commands have an entry point to resolve services.
• Add an ATS-first InteractionExports surface (a tailored internal API rather than a 1:1 DTO mapping of the native types). Inputs are created server-side through factory methods returning an opaque InteractionInputBuilder handle, so callbacks never have to cross the wire as data. Callbacks (dynamic loading, dialog validation) are passed as method parameters and registered as callback handles; the engine marshals a curated context back to the client.
• Implement the full interaction surface: promptConfirmation, promptMessageBox, promptNotification, promptInput, promptInputs, input factories (createTextInput/createSecretInput/createBooleanInput/createNumberInput/createChoiceInput), withChoiceOptions/withValue/withDynamicLoading, and the inputs-dialog validationCallback.

Notable details for reviewers

• Non-serializable callbacks stripped from results. InteractionInput.DynamicLoading holds a Func and is sanitized out of interaction results at runtime (ToResultInput), and the property is [AspireExportIgnore]'d so it no longer appears on the polyglot read-back surface (it was always null on the wire). This is the fix for the original "Serialization of System.Func is not supported" crash.
• By-name input access everywhere. Input collections (the validation context, command arguments, and the multi-input prompt result) expose name-based accessors (value/get for optional lookup, requiredValue/required to throw when missing), so callers read ctx.inputs().value("color") instead of scanning an array. To make this work on the prompt result, InputsInteractionResult is modeled as a handle ([AspireExport(ExposeProperties = true)]) so it surfaces the same InteractionInputCollection (result.inputs()) and a result.canceled() accessor, reusing the proven validation/argument-collection pattern.
• validationCallback lives on the options object (alongside primaryButtonText, etc.), mirroring the C# InputsDialogInteractionOptions shape, now that callbacks can be carried on DTOs.
• Choice options are ordered. Choices are an array of { value, label } entries so option order is preserved across the wire.
• Validation callbacks reuse the already-curated InputsDialogValidationContext (its raw IServiceProvider is [AspireExportIgnore]'d). The shared InputsDialogInteractionOptions.Default singleton is never mutated.
• withCommand test bench. The polyglot bench apps in tests/PolyglotAppHosts exercise the full surface (including a dynamically-loaded options command and dialog validation) in all four languages, providing per-member coverage.
• Generated artifacts. ats.txt and the five language snapshots are regenerated. Per repo convention, generated-shape behavior is validated through the polyglot bench apps rather than unit tests asserting code shape.

Manual end-to-end validation was done by building custom app hosts and driving the dashboard in a browser: input validation (required/reserved errors keep the dialog open, valid input closes it) and dynamic options (alwaysLoadOnStart populates choices, dependsOnInputs reloads them on dependency change) both work with no serialization or RPC errors.

Fixes # (issue)

TypeScript examples

The interaction service is resolved from the command context's service provider. All examples come from the polyglot test bench (tests/PolyglotAppHosts/Aspire.Hosting/TypeScript/apphost.mts).

Resolve the service from a command callback:

await container.withCommand("greet", "Greet", async (ctx) => {
    const interactionService = await ctx.serviceProvider().getInteractionService();
    if (!(await interactionService.isAvailable())) {
        return { success: true, message: "Interaction service is not available." };
    }
    // ...
});

Message-style prompts (confirmation, message box, notification):

const confirmation = await interactionService.promptConfirmation("Confirm", "Proceed?", {
    primaryButtonText: "Yes", secondaryButtonText: "No", showSecondaryButton: true
});

const notification = await interactionService.promptNotification("Heads up", "Something happened.", {
    intent: MessageIntent.Warning, linkText: "Learn more", linkUrl: "https://aspire.dev"
});

Create inputs through factory methods (each returns an opaque server-side builder handle). Choices are an ordered array of { value, label } entries:

const name = await interactionService.createTextInput("name", {
    label: "Name", required: true, placeholder: "Jane Doe", maxLength: 64
});
const password = await interactionService.createSecretInput("password", { required: true });
const enabled = await interactionService.createBooleanInput("enabled", { value: "true" });
const count = await interactionService.createNumberInput("count", { value: "1" });
const color = await interactionService.createChoiceInput("color", {
    choices: [{ value: "r", label: "Red" }, { value: "g", label: "Green" }],
    options: { allowCustomChoice: true }
});

// Builder methods chain off the handle.
const greeting = await interactionService.createTextInput("greeting").withValue("hello");
const size = await interactionService
    .createChoiceInput("size")
    .withChoiceOptions([{ value: "s", label: "Small" }, { value: "l", label: "Large" }]);

Dynamically loaded options. The callback runs server-side and reads other inputs through the load context, so no delegate is ever serialized:

const region = await interactionService.createChoiceInput("region", {
    choices: [{ value: "us", label: "United States" }, { value: "eu", label: "Europe" }]
});

const zone = await interactionService
    .createChoiceInput("zone")
    .withDynamicLoading(async (loadContext) => {
        const selectedRegion = await loadContext.getInputValue("region");
        await loadContext.setChoiceOptions(selectedRegion === "eu"
            ? [{ value: "eu-west", label: "EU West" }, { value: "eu-north", label: "EU North" }]
            : [{ value: "us-east", label: "US East" }, { value: "us-west", label: "US West" }]);
    }, { alwaysLoadOnStart: true, dependsOnInputs: ["region"] });

const result = await interactionService.promptInputs(
    "Pick a zone",
    "Choose a region, then pick a zone from the dynamically loaded options.",
    [region, zone]);

// The result is a handle: read cancellation and look up submitted values by name.
if (!(await result.canceled())) {
    const selectedZone = await result.inputs().value("zone");
}

Single and multi-input prompts with a dialog validation callback. The callback lives on the options argument (next to primaryButtonText) and runs server-side, reading submitted values by name:

const single = await interactionService.promptInput(
    "Single input", "Enter a value.",
    interactionService.createTextInput("solo"),
    {
        primaryButtonText: "Save",
        validationCallback: async (validationContext) => {
            const solo = await validationContext.inputs().value("solo");
            if (!solo) {
                await validationContext.addValidationError("solo", "A value is required.");
            }
        }
    });

const soloValue = single.input?.value;

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17959

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17959"

[Copilot]

Pull request overview

This PR exposes Aspire’s IInteractionService to polyglot app hosts by extending the ATS/JSON-RPC surface with interaction-specific exports and handle-based input builders so delegate-bearing callbacks (dynamic loading, validation) don’t need to serialize across the wire.

Changes:

• Exposes ExecuteCommandContext.ServiceProvider to polyglot command callbacks and adds an ATS export to resolve IInteractionService from that provider.
• Introduces an ATS-first interaction surface (InteractionExports) including prompt APIs, input factories, dynamic-loading context, and validation callback plumbing.
• Regenerates ATS shape + polyglot SDK snapshots and updates polyglot bench app hosts to exercise the new interaction APIs (including dynamic loading + validation).

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
tests/PolyglotAppHosts/Aspire.Hosting/TypeScript/apphost.mts	Adds TypeScript bench commands to exercise the interaction service surface (dynamic loading + validation).
tests/PolyglotAppHosts/Aspire.Hosting/Python/apphost.py	Adds Python bench commands to exercise interaction prompts, inputs, dynamic loading, and validation.
tests/PolyglotAppHosts/Aspire.Hosting/Java/AppHost.java	Adds Java bench commands to exercise interaction prompts, inputs, dynamic loading, and validation.
tests/PolyglotAppHosts/Aspire.Hosting/Go/apphost.go	Adds Go bench commands to exercise interaction prompts, inputs, dynamic loading, and validation.
tests/Aspire.Hosting.CodeGeneration.TypeScript.Tests/Snapshots/TwoPassScanningGeneratedAspire.verified.ts	Updates generated TypeScript SDK snapshot to include the interaction service + input builder handles and related DTOs.
tests/Aspire.Hosting.CodeGeneration.Rust.Tests/Snapshots/TwoPassScanningGeneratedAspire.verified.rs	Updates generated Rust SDK snapshot for interaction service, DTOs, and handle wrappers.
tests/Aspire.Hosting.CodeGeneration.Python.Tests/Snapshots/TwoPassScanningGeneratedAspire.verified.py	Updates generated Python SDK snapshot for interaction service, DTOs, and handle wrappers.
tests/Aspire.Hosting.CodeGeneration.Go.Tests/Snapshots/TwoPassScanningGeneratedAspire.verified.go	Updates generated Go SDK snapshot for interaction service, DTOs, and handle wrappers.
src/Aspire.Hosting/IInteractionService.cs	Excludes InteractionInput.DynamicLoading from the ATS surface to avoid delegate serialization.
src/Aspire.Hosting/Ats/InteractionExports.cs	Adds ATS exports and supporting DTO/handle types for prompts, input factories/builders, dynamic loading, and validation callbacks.
src/Aspire.Hosting/Ats/AtsTypeMappings.cs	Adds ATS export mapping for IInteractionService.
src/Aspire.Hosting/ApplicationModel/ResourceCommandAnnotation.cs	Removes ATS ignore on ExecuteCommandContext.ServiceProvider to enable service resolution from polyglot command callbacks.
src/Aspire.Hosting/api/Aspire.Hosting.ats.txt	Regenerates ATS shape to include the interaction-related handles, DTOs, and capabilities.
src/Aspire.Hosting.CodeGeneration.TypeScript/Resources/base.mts	Removes InteractionInput.dynamicLoading from the TypeScript base model to match ATS-ignore behavior.

[github-actions]

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.
GitHub was asked to rerun all failed jobs for that attempt, and the rerun is being tracked in the rerun attempt.
The job links below point to the failed attempt jobs that matched the retry-safe transient failure rules.

• Tests / Run VS Code extension E2E tests / VS Code extension E2E (Windows, debug-dashboard) - Job-level runner or infrastructure failure matched the transient allowlist.

[github-actions]

Re-running the failed jobs in the CI workflow for this pull request because 4 jobs were identified as retry-safe transient failures in the CI run attempt.
GitHub was asked to rerun all failed jobs for that attempt, and the rerun is being tracked in the rerun attempt.
The job links below point to the failed attempt jobs that matched the retry-safe transient failure rules.

• Tests / Hosting-1 / Hosting-1 (windows-latest) - Job-level runner or infrastructure failure matched the transient allowlist.
• Tests / Templates-XUnit_V2_NewUpAndBuildSupportProjectTemplatesTests / Templates-XUnit_V2_NewUpAndBuildSupportProjectTemplatesTests (windows-latest) - Failed step 'Set up .NET Core' matched the transient annotation allowlist.
• Tests / Run VS Code extension E2E tests / VS Code extension E2E (Windows, zero-to-running) - Job-level runner or infrastructure failure matched the transient allowlist.
• Tests / Cli.EndToEnd-KubernetesDeployWithGarnetTests / Cli.EndToEnd-KubernetesDeployWithGarnetTests (ubuntu-latest) - Test execution failure will be retried because 1 failed test(s) matched transient test failure patterns (Unable to access container registry during publish).

Matched test failure patterns (1 test)

• Aspire.Cli.EndToEnd.Tests.KubernetesDeployWithGarnetTests.DeployK8sWithGarnet — Unable to access container registry during publish

[sebastienros]

Let me know if you think we should try the DTO again to be closer to the C# API since we support callbacks in them with #17950

[davidfowl]

@sebastienros where?

[davidfowl]

pr-testing report?

[JamesNK]

Let me know if you think we should try the DTO again to be closer to the C# API since we support callbacks in them with #17950

Can you give an example of what using interaction service as DTOs would look like? It seems like we should stick to the .NET API unless there is a good reason not to.

In the .NET API the inputs passed in are mutated with the set value (at least, I remember from memory). For example, region.Value and zone.Value have their values set in this example if the prompt was successful:

const result = await interactionService.promptInputs(
    "Pick a zone",
    "Choose a region, then pick a zone from the dynamically loaded options.",
    [region, zone]);

Does the TypeScript API work the same way? A test to check would be good.
The result.Data also returns the passed in list of inputs. Are they the same references?
Can inputs be accessed from the result collection by name? (there is an indexer for getting them by name on InputsCollection)

[JamesNK]

I see this kind of code in some of the samples:

const selectedColor = multi.inputs?.find(input => input.name === "color")?.value;

const name = inputs.find(input => input.name === "name");
if (name?.value === "bad") {
    await validationContext.addValidationError("name", "Name cannot be 'bad'.");
}

There should be an easy way to get an input by name. See examples of using .NET API:

aspire/src/Aspire.Hosting.Azure/Provisioning/Internal/RunModeProvisioningContextProvider.cs

Lines 269 to 270 in 3224b6c

	var subscriptionId = context.AllInputs[SubscriptionIdName].Value ?? string.Empty;
	var resourceGroupName = context.AllInputs[ResourceGroupName].Value ?? string.Empty;

[sebastienros]

PR Testing Report

PR Information

• PR Number: Expose IInteractionService to polyglot app hosts #17959
• Title: Expose IInteractionService to polyglot app hosts
• Head Commit: 0c5539d
• Tested At: 2026-06-08T11:15 -07:00
• Execution Target: Local (isolated temp dir), TypeScript bench

CLI Version Verification

• Expected Commit (PR head): 0c5539d
• Installed Version: 13.5.0-pr.17959.g0c5539d4
• Status: PASS - version contains the PR head short SHA g0c5539d4
• Hive: Aspire.Hosting.13.5.0-pr.17959.g0c5539d4.nupkg present in PR hive

Changes Analyzed (23 files)

• Hosting (5): Ats/InteractionExports.cs (new polyglot surface), ResourceCommandAnnotation.cs (ServiceProvider exposure), AtsTypeMappings.cs, IInteractionService.cs, api/Aspire.Hosting.ats.txt
• CodeGen (5): Go, Java, Python, Rust, TypeScript generators (incl. new InteractionInputCollection by-name accessors)
• Polyglot benches (4): TypeScript/Python/Go/Java app hosts
• Tests/snapshots (9): 7 verified snapshots + RemoteHost round-trip test
• No CLI / Dashboard / Template / Component code changes.

Test Scenarios Executed

Scenario 1: CLI install + version gate

Objective: Install the PR CLI via the dogfood script and confirm it matches the PR head.
Coverage Type: Happy path
Status: PASS

• Dogfood install succeeded; package version suffix pr.17959.g0c5539d4.
• aspire --version -> 13.5.0-pr.17959.g0c5539d4 (matches head 0c5539d).
• Note: the head-commit native CLI archive was still building at first attempt; retried after the macOS ARM64 archive job completed.

Scenario 2: SDK regeneration from the PR build (aspire restore)

Objective: Regenerate the TypeScript SDK from the PR's Aspire.Hosting and confirm the new polyglot interaction API surface is present.
Coverage Type: Happy path (core functional)
Status: PASS

aspire restore regenerated .aspire/modules/{aspire.mts, base.mts, transport.mts} from the PR hive. Verified the three requested layers plus design details:

• ServiceProvider on ExecuteCommandContext: services(): ServiceProviderPromise + IServiceProvider handle generated on the command context.
• InteractionService exports + impl: InteractionService interface, InteractionServiceImpl, and InteractionServicePromise generated; reachable as the new polyglot service.
• IInteractionService implementation surface: prompt inputs/message box/notification factories present.
• Handle-based factory for non-serializable callbacks: withDynamicLoading(callback: (arg: InteractionInputLoadContext) => Promise<void>, options?) uses an opaque InteractionInputLoadContext handle (the factory/opaque-handle design for callbacks that can't be DTO-serialized).
• validationCallback on the options DTO: validationCallback?: (arg: InputsDialogValidationContext) => Promise<void> lives on the options object.
• Cross-language parity accessors: InteractionInputCollection exposes get / required / value / requiredValue (base.mts), matching the Go/Java/Python accessors added in this branch.

Scenario 3: AppHost typecheck against regenerated SDK (tsc --noEmit)

Objective: Confirm the public API is consumable and sound in real TypeScript caller code.
Coverage Type: Happy path
Status: PASS

npm run build (tsc --noEmit) exited 0. The 44 KB bench app host exercises every new member - getInteractionService, prompt input/inputs, message box, notification, withDynamicLoading, dynamic pick-zone / interaction-showcase commands, and validation callbacks - and it all typechecks cleanly against the regenerated PR SDK.

Scenario 4 (soundness): GetInputValue nullability contract

Objective: Validate an earlier review concern that the generated getInputValue typed as non-nullable Promise<string> could be unsound.
Coverage Type: Boundary / contract
Status: PASS (no defect)

The generated surface is getInputValue(inputName: string): Promise<string>. The C# implementation returns input.Value ?? string.Empty (and empty string when the input is absent) and is documented to never return null. The non-nullable generated type is therefore correct across languages; the earlier review concern is resolved by the empty-string contract.

Unhappy-Path Coverage

• Validation rejection (name == "bad" / empty "solo"): the strongly-typed validationCallback paths compile against the new DTO callback contract (covered by Scenario 3). Fully triggering the rejection at runtime requires interactive dashboard input plus runnable resources, which this fixture intentionally lacks - reported as a limitation, not a failure.

Notes / Limitations

• No full orchestration run: the TypeScript bench is a code-generation / typecheck validation fixture, not a runnable app. Its resources reference non-existent ./app, ./src/MyProject, ./src/CSharpApp paths and Azure resources (vnet/aks), so aspire start is not applicable. Validation here is correctly centered on SDK regeneration + typecheck, which exercise the full generated API contract end-to-end.

Summary

Scenario	Status	Notes
1. CLI install + version gate	PASS	13.5.0-pr.17959.g0c5539d4 == head 0c5539d
2. SDK regeneration (restore)	PASS	All 3 layers + dynamic-loading handle + validationCallback + parity accessors present
3. AppHost typecheck (tsc)	PASS	Full bench compiles against regenerated SDK (exit 0)
4. GetInputValue contract	PASS	Non-nullable type is sound (empty-string contract)

Overall Result

PR VERIFIED for the polyglot IInteractionService API surface.

Recommendations

• Consider adding a minimal runnable polyglot interaction sample (real resources, no Azure) so the dynamic-loading and validation flows can be exercised at runtime, not only typechecked.

[github-actions]

Re-running the failed jobs in the CI workflow for this pull request because 3 jobs were identified as retry-safe transient failures in the CI run attempt.
GitHub was asked to rerun all failed jobs for that attempt, and the rerun is being tracked in the rerun attempt.
The job links below point to the failed attempt jobs that matched the retry-safe transient failure rules.

• Tests / Qdrant.Client / Qdrant.Client (ubuntu-latest) - Test execution failure will be retried because 1 failed test(s) matched transient test failure patterns (Unable to access container registry during publish).
• Tests / Hosting.Docker / Hosting.Docker (ubuntu-latest) - Test execution failure will be retried because 1 failed test(s) matched transient test failure patterns (Unable to access container registry during publish).
• Tests / Cli.EndToEnd-KubernetesDeployWithRabbitMQTests / Cli.EndToEnd-KubernetesDeployWithRabbitMQTests (ubuntu-latest) - Test execution failure will be retried because 1 failed test(s) matched transient test failure patterns (Unable to access container registry during publish).

Matched test failure patterns (1 test)

• Aspire.Cli.EndToEnd.Tests.KubernetesDeployWithRabbitMQTests.DeployK8sWithRabbitMQ — Unable to access container registry during publish

[sebastienros]

@JamesNK added by-name accessors to all the input collections so you don't have to scan arrays. It works the same on validation inputs, command arguments, and the multi-input prompt result:

// validation
const color = await ctx.inputs().value("color");

// multi-input result
const result = await interactions.promptInputs(...);
if (!await result.canceled()) {
  const color = await result.inputs().value("color");
}

The result is now a handle (like the validation context), so inputs() returns the same InteractionInputCollection. Accessors available: get/value (optional) and required/requiredValue (throw if missing).

[github-actions]

❓ CLI E2E Tests unknown — 113 passed, 0 failed, 2 unknown (commit 6d0e481)

View all recordings

-	Test	Detail
✅	AddPackageInteractiveWhileAppHostRunningDetached	Recording · Job · CLI logs
✅	AddPackageWhileAppHostRunningDetached	Recording · Job · CLI logs
✅	AgentCommands_AllHelpOutputs_AreCorrect	Recording · Job · CLI logs
✅	AgentInitCommand_DefaultSelection_InstallsDefaultSkills	Recording · Job · CLI logs
✅	AgentInitCommand_MigratesDeprecatedConfig	Recording · Job · CLI logs
✅	AgentInit_NonInteractive_BundleOnlySkillsNotInCatalog	Recording · Job · CLI logs
✅	AgentMcpListStructuredLogsReturnsLogsFromStarterApp	Recording · Job · CLI logs
✅	AgentMcpListStructuredLogsReturnsLogsFromStarterApp_DevLocalhost	Recording · Job · CLI logs
✅	AgentMcpListStructuredLogsReturnsLogsFromStarterApp_Isolated	Recording · Job · CLI logs
✅	AllPublishMethodsBuildDockerImages	Recording · Job · CLI logs
✅	AspireAddAndStartWorkAgainstLegacyAppHostTs	Recording · Job · CLI logs
✅	AspireAddPackageVersionToDirectoryPackagesProps	Recording · Job · CLI logs
✅	AspireInitSingleFileAppHostRunsViaDotnetRunAppHost	Recording · Job · CLI logs
✅	AspireInit_ExistingAppHostDir_RecreatesNuGetConfigKeepsFiles	Recording · Job · CLI logs
❔	AspireInit_SolutionFile_BuildsAgainstChannelHive	Recording · Job · CLI logs
✅	AspireStartUpdatesStaleTypeScriptAppHostPath	Recording · Job · CLI logs
✅	AspireUpdateRemovesAppHostPackageVersionFromDirectoryPackagesProps	Recording · Job · CLI logs
✅	AspireUpdateRemovesOrphanAppHostPackageVersionWhenSdkAlreadyCurrent	Recording · Job · CLI logs
✅	Banner_DisplayedOnFirstRun	Recording · Job · CLI logs
✅	Banner_DisplayedWithExplicitFlag	Recording · Job · CLI logs
✅	Banner_NotDisplayedWithNoLogoFlag	Recording · Job · CLI logs
✅	CertificatesClean_RemovesCertificates	Recording · Job · CLI logs
✅	CertificatesTrust_WithNoCert_CreatesAndTrustsCertificate	Recording · Job · CLI logs
✅	CertificatesTrust_WithUntrustedCert_TrustsCertificate	Recording · Job · CLI logs
✅	ConfigSetGet_CreatesNestedJsonFormat	Recording · Job · CLI logs
✅	CreateAndRunAspireStarterProject	Recording · Job · CLI logs
✅	CreateAndRunAspireStarterProjectWithBundle	Recording · Job · CLI logs
✅	CreateAndRunEmptyAppHostProject	Recording · Job · CLI logs
✅	CreateAndRunJavaEmptyAppHostProject	Recording · Job · CLI logs
✅	CreateAndRunJsReactProject	Recording · Job · CLI logs
✅	CreateAndRunPolyglotAppHostWithDevLocalhostUrls	Recording · Job · CLI logs
✅	CreateAndRunPythonReactProject	Recording · Job · CLI logs
✅	CreateAndRunTypeScriptEmptyAppHostProject	Recording · Job · CLI logs
✅	CreateAndRunTypeScriptStarterProject	Recording · Job · CLI logs
✅	CreateJavaAppHostWithViteApp	Recording · Job · CLI logs
✅	CreateTypeScriptAppHostWithViteApp_UsesConfiguredToolchain	Recording · Job · CLI logs
✅	DashboardRunWithAgentMcpListTracesReturnsNoTraces	Recording · Job · CLI logs
✅	DashboardRunWithAgentMcpListTracesReturnsNoTraces_DevLocalhost	Recording · Job · CLI logs
✅	DashboardRunWithOtelTracesReturnsNoTraces	Recording · Job · CLI logs
✅	DashboardRunWithOtelTracesReturnsNoTraces_DevLocalhost	Recording · Job · CLI logs
✅	DeployK8sBasicApiService	Recording · Job · CLI logs
✅	DeployK8sWithExternalHelmChart	Recording · Job · CLI logs
✅	DeployK8sWithGarnet	Recording · Job · CLI logs
✅	DeployK8sWithMongoDB	Recording · Job · CLI logs
✅	DeployK8sWithMySql	Recording · Job · CLI logs
✅	DeployK8sWithPostgres	Recording · Job · CLI logs
✅	DeployK8sWithRabbitMQ	Recording · Job · CLI logs
✅	DeployK8sWithRedis	Recording · Job · CLI logs
✅	DeployK8sWithSqlServer	Recording · Job · CLI logs
✅	DeployK8sWithValkey	Recording · Job · CLI logs
✅	DeployTypeScriptAppToKubernetes	Recording · Job · CLI logs
✅	DescribeCommandResolvesReplicaNames	Recording · Job · CLI logs
✅	DescribeCommandShowsRunningResources	Recording · Job · CLI logs
✅	DetachFormatJsonProducesValidJson	Recording · Job · CLI logs
✅	DetachFormatJsonProducesValidJsonWhenRestartingExistingInstance	Recording · Job · CLI logs
✅	DoPublishAndDeployListStepsWork	Recording · Job · CLI logs
✅	DocsCommand_RendersInteractiveMarkdownFromLocalSource	Recording · Job · CLI logs
✅	DoctorCommand_DetectsDeprecatedAgentConfig	Recording · Job · CLI logs
✅	DoctorCommand_TypeScriptAppHostReportsMissingConfiguredToolchain	Recording · Job · CLI logs
✅	DoctorCommand_WithSslCertDir_ShowsTrusted	Recording · Job · CLI logs
✅	DoctorCommand_WithoutSslCertDir_ShowsPartiallyTrusted	Recording · Job · CLI logs
✅	DotNetRunFileBasedAppHostUsesAspireCliBundle	Recording · Job · CLI logs
✅	DotNetRunProjectAppHostUsesAspireCliBundle	Recording · Job · CLI logs
✅	GatewayWithoutExternalEndpoint_FailsPublishWithGuidance	Recording · Job · CLI logs
✅	GeneratedAspireDevScript_StartsWatchMode_WithConfiguredToolchain	Recording · Job · CLI logs
✅	GlobalMigration_HandlesCommentsAndTrailingCommas	Recording · Job · CLI logs
✅	GlobalMigration_HandlesMalformedLegacyJson	Recording · Job · CLI logs
✅	GlobalMigration_PreservesAllValueTypes	Recording · Job · CLI logs
✅	GlobalMigration_SkipsWhenNewConfigExists	Recording · Job · CLI logs
✅	GlobalSettings_MigratedFromLegacyFormat	Recording · Job · CLI logs
✅	IngressWithoutExternalEndpoint_FailsPublishWithGuidance	Recording · Job · CLI logs
✅	InitTypeScriptAppHost_AugmentsExistingViteRepoInWorkspaceSubdirectory	Recording · Job · CLI logs
✅	InteractiveCSharpInitCreatesExpectedFiles	Recording · Job · CLI logs
✅	InvalidAppHostPathWithComments_IsHealedOnRun	Recording · Job · CLI logs
✅	JavaScriptHostingApisRunFromTypeScriptAppHost	Recording · Job · CLI logs
✅	LatestCliCanStartStableChannelAppHost	Recording · Job · CLI logs
✅	LatestCliCanStartStableChannelTypeScriptAppHost	Recording · Job · CLI logs
✅	LegacySettingsMigration_AdjustsRelativeAppHostPath	Recording · Job · CLI logs
✅	LogsCommandShowsResourceLogs	Recording · Job · CLI logs
✅	OtelLogsReturnsStructuredLogsFromStarterApp	Recording · Job · CLI logs
✅	OtelLogsReturnsStructuredLogsFromStarterAppIsolated	Recording · Job · CLI logs
✅	ProcessCommandCallbackReceivesCliArguments	Recording · Job · CLI logs
✅	PsCommandListsRunningAppHost	Recording · Job · CLI logs
✅	PsFormatJsonOutputsOnlyJsonToStdout	Recording · Job · CLI logs
✅	PublishJavaScriptPatternsGeneratesExpectedDockerComposeArtifacts	Recording · Job · CLI logs
✅	PublishWithConfigureEnvFileUpdatesEnvOutput	Recording · Job · CLI logs
✅	PublishWithDockerComposeServiceCallbackSucceeds	Recording · Job · CLI logs
✅	PublishWithoutOutputPathUsesAppHostDirectoryDefault	Recording · Job · CLI logs
✅	ResourceCommand_FailedExec_ShowsLogPathAndLogHasEntries	Recording · Job · CLI logs
✅	ResourceCommand_SetAndDeleteParameterUpdatesDescribeOutput	Recording · Job · CLI logs
✅	RestoreGeneratesSdkFiles	Recording · Job · CLI logs
✅	RestoreGeneratesSdkFiles_WithConfiguredToolchain	Recording · Job · CLI logs
✅	RestoreRefreshesGeneratedSdkAfterAddingIntegration	Recording · Job · CLI logs
✅	RestoreSupportsConfigOnlyHelperPackageAndCrossPackageTypes	Recording · Job · CLI logs
✅	RunFromParentDirectory_UsesExistingConfigNearAppHost	Recording · Job · CLI logs
✅	RunReportsSyntaxErrorsForDotNetAppHost	Recording · Job · CLI logs
✅	RunReportsSyntaxErrorsForTypeScriptAppHost	Recording · Job · CLI logs
✅	SecretCrudOnDotNetAppHost	Recording · Job · CLI logs
✅	SecretCrudOnTypeScriptAppHost	Recording · Job · CLI logs
✅	StagingChannel_ConfigureAndVerifySettings_ThenSwitchChannels	Recording · Job · CLI logs
✅	StartAndWaitForTypeScriptSqlServerAppHostWithNativeAssets	Recording · Job · CLI logs
✅	StartReportsSyntaxErrorsForDotNetAppHost	Recording · Job · CLI logs
✅	StartReportsSyntaxErrorsForTypeScriptAppHost	Recording · Job · CLI logs
✅	StopAllAppHostsFromAppHostDirectory	Recording · Job · CLI logs
✅	StopJavaPolyglotAppHostUsingApphostDirectory	Recording · Job · CLI logs
✅	StopNonInteractiveSingleAppHost	Recording · Job · CLI logs
✅	StopTypeScriptPolyglotAppHostUsingApphostDirectory	Recording · Job · CLI logs
✅	StopWithNoRunningAppHostExitsSuccessfully	Recording · Job · CLI logs
✅	TypeScriptAppHostRunDoesNotDeadlockWhenLazyOptionsInvokeAsyncCallback	Recording · Job · CLI logs
✅	TypeScriptAppHostWithVite_AllowsDifferentGuestPkgManager	Recording · Job · CLI logs
✅	UnAwaitedChainsCompileWithAutoResolvePromises	Recording · Job · CLI logs
❔	UpdateToStable_CSharpEmptyAppHost_KeepsConfigChannel	Recording · Job · CLI logs
✅	UpdateToStable_CSharpSingleFileInit_KeepsConfigChannel	Recording · Job · CLI logs
✅	UpdateToStable_TypeScriptSingleFileInit_KeepsConfigChannel	Recording · Job · CLI logs
✅	UpdateToStable_TypeScript_PreviewsStablePkgsAndKeepsChannel	Recording · Job · CLI logs

---

_{📹 Recordings uploaded automatically from CI run #27174145002}