Roo should always relay user messages to LLMs #4587
Description
What specific problem does this solve?
When an automated activity running in a task is interrupted by cancelling, the user is presented with Resume/Terminate buttons. The message user writes to the message box doesn't get relayed to the LLM.
This is a regression in my opinion, a deviation from earlier behaviour.
There are other situations in which Roo "swallows" user messages, some may even be bugs, I would track those in another issue if I am able to figure them out consistently enough, but this is the most obvious one. This one is consistent enough for me to assume it's some kind of a feature, rather than a bug.
It's a costly feature for users, as it often means user needs to waste API points until they finally are allowed the opportunity to steer the LLM with written instructions.
How should this be solved?
I don't think it's valid for Roo not to relay user message in any circumstances, irrespective of the button user chose to click, the state of Roo task etc. If it's time to send something to LLM, that time is always the right time for Roo to relay the text user typed in the message box to the LLM as the more important part of whatever payload it's sending.
How will we know it works? (Acceptance Criteria)
Given any interruption of automated activity or opportunity to send new payload to LLM
When I type a message in the message box
Then Roo should ALWAYS relay the message to the LLM
And should not omit my message irrespective of the button clicked
Estimated effort and complexity
I do not feel comfortable in making any estimations, but I assume that for someone who knows the codebase well this should be a trivial task to implement the only thing this needs is for the messages NOT to be ignored under particular circumstances.
Technical considerations (optional but helpful)
No response
Trade-offs and risks (optional)
The only tradeoff is some people aren't expecting this (who tho, who expects their messages to be "swallowed" and dumped to trash?). Maybe old behaviour can be retained behind a settings boolean if that's the case.
Additional context (optional)
No response
Proposal checklist
- I've searched existing Issues and Discussions for duplicates
- This is a specific, actionable proposal with clear problem and solution
- I've included concrete acceptance criteria
- I understand this needs approval before implementation begins
Interested in implementing this?
- Yes, I'd like to help implement this feature