Support terminal interaction inputs in polyglot AppHosts
- 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
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