microsoft / microsoft/aspire

Support terminal interaction inputs in polyglot AppHosts

Open
#19,970 0 comments 0 reactions 0 assignees View on GitHub
area-hosting area-polyglot
Dominant language
C#
Stars
6.3k
Forks
991
Avg merge
2d 15h
Merged PRs (30d)
196

Description

More information on our issue management policies can be found here: https://aka.ms/aspnet/issue-policies

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

The AppHost-owned terminal interaction feature in #19887 exposes `InputType.Terminal` in generated polyglot SDKs, but `InteractionInput.Terminal` is marked with `AspireExportIgnore`. Non-.NET callers can therefore select a terminal input type without having a supported way to supply the terminal required by `PromptInputsAsync`.

The host rejects that input because `InteractionInput.Terminal` is null. The generated API currently advertises an input variant that polyglot callers cannot construct successfully.

We are accepting this limitation in the initial implementation and tracking the follow-up for **13.6**, rather than adding polyglot support to #19887.

### Describe the solution you'd like

Provide an ATS-compatible way for polyglot AppHosts to create or reference an Aspire-owned terminal and supply it to a terminal interaction input. The exact public API can be designed in this follow-up.

- Keep the process and terminal implementation owned by the AppHost; do not require serializing Hex1b objects or exposing Hex1b as a public API dependency.
- Preserve the existing lifetime contract: the interaction borrows the terminal, and completing or dismissing the dialog does not dispose it.
- Keep the generated SDK input type and its configuration/construction path consistent across supported languages.
- Add focused ATS/code-generation coverage and an end-to-end example demonstrating a valid terminal interaction from a non-.NET AppHost.

An alternative, if a supported construction path is deferred further, is to stop advertising the unsupported terminal input variant in ATS. No such restriction is requested for the initial implementation.

### Additional context

This concerns **AppHost-owned terminal interaction inputs**, not the existing DCP/resource `WithTerminal(...)` support.

Related PR: #19887.

Existing review feedback describing the same gap:
- https://github.com/microsoft/aspire/pull/19887#discussion_r3930651645
- https://github.com/microsoft/aspire/pull/19887#discussion_r3939241840

Relevant implementation: `src/Aspire.Hosting/IInteractionService.cs` (`InputType.Terminal` and `InteractionInput.Terminal`), `src/Aspire.Hosting/InteractionService.cs` (terminal-input validation), and the generated SDK snapshots under `tests/Aspire.Hosting.CodeGeneration.*.Tests/Snapshots/`.

Contributor guide

Open the contributing guide

Research direction

Start with InputType.Terminal and InteractionInput.Terminal in src/Aspire.Hosting/IInteractionService.cs, then read terminal-input validation in src/Aspire.Hosting/InteractionService.cs. Inspect the generated SDK snapshots under tests/Aspire.Hosting.CodeGeneration.*.Tests/Snapshots/ and the related PR discussion before deciding the public API. Done means polyglot AppHosts can create or reference an AppHost-owned terminal, with ATS/code-generation coverage and an end-to-end example.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
backend-api-design, testing, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.