[✨ Triage] dotnet/aspire#10834 by JamesNK - InteractionInputs should be accessiable by name in results

[MihuBot]

Triage for microsoft/aspire#10834.
Repo filter: area-dashboard issues.
MihuBot version: 264315.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

dotnet/aspire#10834: InteractionInputs should be accessiable by name in results by JamesNK
[Tool] Searching for InteractionInput name lookup, IInteractionService.PromptInputsAsync access by name, InputsDialogValidationContext.Inputs dictionary, InteractionInput keyed collection, duplicate input names error, InteractionInput Name property (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/aspire)
[Tool] Found 67 issues, 152 comments, 67 returned results (29653 ms)

Here are the most relevant related issues and discussions for triaging issue #10834 ("InteractionInputs should be accessiable by name in results"):

---

1. PR #10038 (June 2025) - Add Azure provisioning command handling and settings configuration

• Summary: This PR and its discussion are directly relevant. In a comment on July 11, 2025, JamesNK suggests that instead of referencing inputs by index, inputs could be created earlier and assigned to variables, but then questions if inputs should have a name and be accessible by name. He states: "Although I'm starting to wonder if inputs should have a name and be accessible via name here and in the result... Keep referencing by index and in 9.5 I'll change the API to make inputs a KeyedCollection."
• Conclusion: The idea for named access to InteractionInput was already being considered and planned for a future release.

---

2. PR #10835 (August 2025) - [WIP] InteractionInputs should be accessiable by name in results

• Summary: This is a work-in-progress pull request opened immediately after the issue, indicating that work has started to implement the feature described in #10834. The PR description restates the issue and notes that it will fix #10834.
• Conclusion: The feature is actively being worked on.

---

3. Issue #9807 (June 2025) - Prompt for values

• Summary: This issue discusses the need for a service to prompt for values at runtime, including APIs for prompting and returning results. The discussion covers the design of prompting APIs, including the need for forms and validation, and references the IInteractionService and its prompt calls. There is mention of the need for richer metadata and the ability to prompt for multiple values.
• Conclusion: The design and extensibility of the interaction/prompting system, including how results are accessed, has been an ongoing topic.

---

4. PR #10056 (June 2025) - Rename interaction inputs, improve input dialog UX

• Summary: This PR includes renaming interaction input names to be more generalizable and improving the input dialog. While not directly about keyed access, it shows ongoing work to improve the interaction input system.
• Conclusion: Related to the evolution of the input system, but not specifically about keyed access.

---

5. PR #8373 (March 2025) - Dashboard gracefully handles duplicate property names

• Summary: This PR addresses handling duplicate property names in the dashboard, with the "last value wins" when there are duplicates. It notes the need to look at what causes duplicate names in hosting.
• Conclusion: Relevant to the part of #10834 about handling duplicate input names and error messaging.

---

6. Issue #2954 (March 2024) - Handling of duplicate names - "The specified name ... is already in use"

• Summary: This issue discusses the problem of duplicate resource names and how to handle them, including error messaging and guidance. While focused on resource names, it is conceptually similar to the duplicate input name concern in #10834.
• Conclusion: Shows that duplicate name handling is a recurring concern in the project.

---

7. PR #10101 (June 2025) - Implement CLI prompting on top of InteractionService

• Summary: This PR implements CLI prompting using the interaction service. In the comments, there is discussion about how prompts and their results are managed, including the use of dictionaries for completed prompts.
• Conclusion: Indicates that dictionary-based (keyed) access patterns are already being considered in related code.

---

8. PR #9943 (June 2025) - Interaction service

• Summary: This PR introduces the InteractionService and discusses its API design, including how inputs are modeled and accessed. There is a comment about having one class for all input types and ignoring properties that don't apply.
• Conclusion: Shows the foundational work for the interaction input system.

---

9. PR #10419 (July 2025) - Fix duplicate storage resource names

• Summary: Fixes issues with duplicate resource names, which is analogous to the duplicate input name error handling proposed in #10834.
• Conclusion: Reinforces the importance of clear error handling for duplicates.

---

Summary

• The need for named/keyed access to InteractionInput instances has been discussed and was planned for a future release (see PR #10038).
• Duplicate name handling and error messaging is a recurring theme in the repository, both for resources and for interaction inputs.
• Work on this feature is already underway (see PR #10835).
• The overall design of the interaction service and its extensibility for richer input/result handling has been an ongoing topic.

No existing issue or PR appears to implement the exact feature yet, but the groundwork and related discussions are present, and the work is now in progress.

---

Most Relevant Links

• PR #10038 - Add Azure provisioning command handling and settings configuration
• PR #10835 - [WIP] InteractionInputs should be accessiable by name in results
• PR #8373 - Dashboard gracefully handles duplicate property names
• Issue #9807 - Prompt for values
• PR #10101 - Implement CLI prompting on top of InteractionService

Let me know if you need a deeper dive into any specific discussion or code change!