[✨ Triage] dotnet/aspire#10368 by davidfowl - Extend ExecuteCommandResult to support cancellation of interactions

[MihuBot]

Triage for dotnet/aspire#10368.
Repo filter: area-dashboard issues.
MihuBot version: 4431de.
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#10368: Extend ExecuteCommandResult to support cancellation of interactions by davidfowl
[Tool] Searching for ExecuteCommandResult cancellation, interaction service dialog cancel, command cancel interaction, dismiss interaction dialog, command result states (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/aspire)
[Tool] Found 50 issues, 90 comments, 50 returned results (6771 ms)
[Tool] Obtained 37 comments for issue #9943: Interaction service
[Tool] Obtained 4 comments for issue #10049: InteractionService should expose `InteractionInput`-based APIs for requesting confirmation
[Tool] Obtained 0 comments for issue #10257: Don't throw in interaction service when no inputs
[Tool] Obtained 2 comments for issue #9311: [nit]: "Operation cancelled by user action" log is too incessant
[Tool] Obtained 18 comments for issue #9807: Prompt for values

Here are the most relevant related issues and discussions for triaging issue #10368 ("Extend ExecuteCommandResult to support cancellation of interactions"):

---

1. PR #9943 (June 2025) - "Interaction service"

• Introduced the InteractionService for prompting users in the dashboard and (in the future) CLI.
• Key related discussion:
  • There was explicit feedback (from @maddymontaquila and @davidfowl) about how cancellations are currently surfaced as "Failure" in the UI, and a suggestion to "special case" cancellations so that they don't show as errors but as "Command execution canceled by user" or similar.
  • Images were shared showing the current (possibly confusing) UI for canceled commands.
  • The need for a cancellation state distinct from error/success was raised, but not implemented in this PR.
  • The PR author and reviewers agreed that this is an area for future improvement.
• Conclusion:
  • The need for a cancellation state in command results is recognized, and the current implementation does not distinguish between error and cancellation. This aligns directly with the new issue's request.

---

2. Issue #10049 (June 2025) - "InteractionService should expose InteractionInput-based APIs for requesting confirmation"

• Discusses how confirmations and input interactions are modeled in the InteractionService.
• Key related discussion:
  • There is a debate about whether confirmation dialogs and boolean inputs (like checkboxes) should be unified under a single interaction type.
  • The discussion touches on the semantics of user dismissal/cancellation and how it should be represented in the API and UI.
• Conclusion:
  • While not directly about command result states, this issue shows ongoing work to clarify and unify how user interactions (including cancellations) are modeled, which is relevant to the requested feature.

---

3. PR #10257 (July 2025) - "Don't throw in interaction service when no inputs"

• Fixes an issue where canceling an input dialog would throw an exception.
• Conclusion:
  • This is a technical fix for dialog cancellation, but does not address the user experience or result state for canceled commands.

---

4. Issue #9311 (May 2025) - "[nit]: 'Operation cancelled by user action' log is too incessant"

• Discusses the annoyance of seeing "Operation cancelled by user action" logs every time a command is interrupted (e.g., via Ctrl-C).
• Conclusion:
  • This is about log noise, not UI or command result states, but it shows a general desire to treat cancellations as a normal, non-error outcome.

---

5. Issue #9807 (June 2025, closed July 2025) - "Prompt for values"

• Discusses the design of prompting for user input, including how to handle cancellation.
• Key related discussion:
  • The flow for canceling an interaction is described: "If the user clicks cancel then that notification is sent back."
  • The need for a clear API and result for cancellation is implied, but not fully specified.
• Conclusion:
  • The infrastructure for handling cancellations is being built, but the specific request to have a cancellation state in ExecuteCommandResult is not yet implemented.

---

6. PR #2572 (March 2024) - "Resource Command Support"

• Early implementation of command execution and result reporting.
• Key related comment:
  • There is a technical note about combining cancellation tokens, but no discussion of a distinct cancellation result state.

---

7. Other related items

• There are several issues and PRs about cancellation handling in logs, async enumerables, and resource shutdown, but none address the user-facing result state for canceled commands in the interaction service.

---

Summary and Recommendation

• There is clear prior discussion (especially in PR #9943) about the need to distinguish cancellation from error in command results, and this is recognized as a gap in the current implementation.
• No existing issue or PR has implemented a "cancellation" state in ExecuteCommandResult or prevented a message from being shown for canceled commands.
• The new issue is valid, not a duplicate, and is aligned with ongoing feedback and design discussions.

References:

• PR #9943 - Interaction service
• Issue #10049 - InteractionService should expose InteractionInput-based APIs for requesting confirmation
• PR #10257 - Don't throw in interaction service when no inputs
• Issue #9311 - "Operation cancelled by user action" log is too incessant
• Issue #9807 - Prompt for values
• PR #2572 - Resource Command Support

---

Conclusion:
The request in issue #10368 is not yet implemented, but is well-motivated by prior discussions and feedback. It is a logical next step for improving the user experience of command interactions in Aspire.