Add support for intent-progress assist events #24143
Conversation
src/components/ha-assist-chat.ts
Outdated
| if (delta.role) { | ||
| // If currentDeltaRole exists, it means we're receiving our | ||
| // second or later message. Let's add it to the chat. | ||
| // Reuse the previous message if it had no content |
There was a problem hiding this comment.
I can't find where "if it had no content" is happening.
I read this as this block is checking if the existing message has content and appending to it but otherwise dropping the final delta. Is the point here that if there is already content then a delta with an assistant role is empty and ends the message?
There was a problem hiding this comment.
If the previous message had no content that we shown, the content of hassMessage is still equal to …. So we check that on line 501:
hassMessage.text !== "…"There was a problem hiding this comment.
I feel i am missing something silly:
- If it is "..." then it has no content.
- If it is not "..." then it has content.
There was a problem hiding this comment.
I read hassMessage.text !== "…" as "the message has content"
There was a problem hiding this comment.
Right. So if a new message comes in, and the previous message no longer just contains …, some content was added. In that case, we add a second message to the log and start adding the deltas to that one. You can see that happen in the video above, where a 2nd "role" comes in, and it starts a new chat bubble.
There was a problem hiding this comment.
OK i think removing "Reuse the previous message if it had no content" would be helpful since its covered by the comment "new message and previous message has content". That comment implies to me that its part of the if statement, but its not, its part of the fact that the delta is arriving.
| if (delta.role) { | ||
| // If currentDeltaRole exists, it means we're receiving our | ||
| // second or later message. Let's add it to the chat. | ||
| if (currentDeltaRole && delta.role && hassMessage.text !== "…") { |
There was a problem hiding this comment.
OK so can hassMessage.text ever be ... in this case? If so, then it seems like we drop the delta. (If not then just always overwrite instead and drop the check for hassMessage.text).
The way i read this is: The existing value should just decide of ... is stripped but as written it also deciding if the delta is appending.
There was a problem hiding this comment.
I'm still now confused by:
- we update
hassmessage.text - then replace
hassmessageentirely
There was a problem hiding this comment.
yes it can be if the first message only contained tool calls and no content.
There was a problem hiding this comment.
if we don't have this check, we will end up with an empty speech bubble (because the Assistant message had no content.
There was a problem hiding this comment.
- User to Assistant: Turn on the lights in the living room
- Assistant to HA: tool-call: turn on lights
- HA to Assistant: tool-call-result: lights turned on
- Assistant to User: the lights have been turned on
There was a problem hiding this comment.
What is this doing? Why update .text to then overwrite the entire object?
hassMessage.text = ...
hassMessage = {...}
There was a problem hiding this comment.
hassMessage is a pointer to an object that is already being rendered. When we update text and call request update, it re-renders it. Add message also rerenders it.
While we’re receiving content, we always have … at the end of the message that we’re processing (see video). When a second message comes in, we remove the … from the current last message and then add a new message.
Breaking change
Proposed change
Leverage new intent-progress events from home-assistant/core#138095 to show partial responses as soon as they come available. Is backwards compatible with the original events.
CleanShot.2025-02-07.at.22.09.39.mp4
Type of change
Example configuration
Additional information
Checklist
If user exposed functionality or configuration variables are added/changed: