[FEATURE]: Cancel queued user message without affecting session loop #9160

Closed
opened 2026-02-16 18:11:47 -05:00 by yindo · 2 comments
Owner

Originally created by @zenyr on GitHub (Feb 12, 2026).

Originally assigned to: @thdxr on GitHub.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Queued user messages cannot be cancelled cleanly today. Users have to wait or interrupt the session loop, which is disruptive and can lead to unintended behavior.

Proposal
Add a cancel action for a specific queued message that removes it from the database without impacting the running session loop.

User Experience

  • Add a "Cancel queued message" action in the message UI.
  • (Optional) confirm the cancel action depending on existing UX patterns.

API

  • Endpoint: POST /session/{sessionID}/cancel/{messageID}
  • Behavior: remove queued message from storage; do not stop the session loop.
  • Response: boolean success.

SDK

  • Expose client.session.cancel({ sessionID, messageID, directory? }).
  • Regenerate OpenAPI/SDK outputs.

Acceptance Criteria

  • Can cancel a queued message without stopping the session.
  • Cancelled message is removed from the queue and no longer processed.
  • SDK and OpenAPI are updated and documented.
  • UI reflects the cancelled state.
Originally created by @zenyr on GitHub (Feb 12, 2026). Originally assigned to: @thdxr on GitHub. I have verified this feature I'm about to request hasn't been suggested before. ## Describe the enhancement you want to request Queued user messages cannot be cancelled cleanly today. Users have to wait or interrupt the session loop, which is disruptive and can lead to unintended behavior. **Proposal** Add a cancel action for a specific queued message that removes it from the database without impacting the running session loop. **User Experience** - Add a \"Cancel queued message\" action in the message UI. - (Optional) confirm the cancel action depending on existing UX patterns. **API** - Endpoint: `POST /session/{sessionID}/cancel/{messageID}` - Behavior: remove queued message from storage; do not stop the session loop. - Response: boolean success. **SDK** - Expose `client.session.cancel({ sessionID, messageID, directory? })`. - Regenerate OpenAPI/SDK outputs. **Acceptance Criteria** - Can cancel a queued message without stopping the session. - Cancelled message is removed from the queue and no longer processed. - SDK and OpenAPI are updated and documented. - UI reflects the cancelled state.
yindo closed this issue 2026-02-16 18:11:47 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Feb 12, 2026):


This issue might be a duplicate of or overlap with existing work. Please check:

  • #5333: [FEATURE]: Graceful handling of queued messages after session interrupt - includes UI for canceling individual queued messages
  • #8685: [FEATURE]: Better controls/UX for queued messages - requests edit and cancel options
  • #12707: feat(app): queued message controls with send now in prompt - already implements queued message controls

Your feature request is well-written and compliant. However, consider collaborating on #5333 which appears to be the most comprehensive approach to queued message management.

@github-actions[bot] commented on GitHub (Feb 12, 2026): --- This issue might be a duplicate of or overlap with existing work. Please check: - #5333: [FEATURE]: Graceful handling of queued messages after session interrupt - includes UI for canceling individual queued messages - #8685: [FEATURE]: Better controls/UX for queued messages - requests edit and cancel options - #12707: feat(app): queued message controls with send now in prompt - already implements queued message controls Your feature request is well-written and compliant. However, consider collaborating on #5333 which appears to be the most comprehensive approach to queued message management.
Author
Owner

@zenyr commented on GitHub (Feb 12, 2026):

Duplicate of #5333.

@zenyr commented on GitHub (Feb 12, 2026): Duplicate of #5333.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#9160