Repository navigation
Conversation
When Assist runs through a pipeline (phone app, satellite), Home Assistant always supplies a conversation id. `_resolve_conversation_id` checked that id first, so the `assist_user_<id>` branch was never reached and the agent cannot tell which HA user is speaking. The user id is not sent any other way. Observed on 0.1.65 with `voice_agent_id: home` and no session override: a turn from the HA phone app landed in `agent:home:01m4hf34nxm64w74ab60v9pbrc`. The same agent called through `/api/conversation/process` without a conversation id landed in `agent:home:assist_user_<id>`. Change: the base-id choice moves to `helpers.assist_base_session_id`. When both a signed-in user and a conversation id are present, the key is `assist_user_<id>:<conversation>`: still one session per conversation, as today, and the agent can now see the speaker. A follow-up turn that hands back a key already carrying the user is kept as is, so it is never prefixed twice. Without a user the order is unchanged (conversation id, then device, then `assist_default`). The "Assist session ID override" still wins when set, and agent scoping is unchanged. README: one line under "Model selection" describes the key. Tests: added `AssistBaseSessionIdTests` (7 cases, including a scoped follow-up round trip); `python -m unittest discover -s tests -v` passes (16 tests), plus the Python syntax check and `node --check` from the validate workflow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When Assist runs through a pipeline (phone app, satellite), Home Assistant always supplies a conversation id.
_resolve_conversation_idchecked that id first, so theassist_user_<id>branch was never reached and the agent cannot tell which HA user is speaking. The user id is not sent any other way.Observed on 0.1.65 with
voice_agent_id: homeand no session override: a turn from the HA phone app landed inagent:home:01m4hf34nxm64w74ab60v9pbrc. The same agent called through/api/conversation/processwithout a conversation id landed inagent:home:assist_user_<id>.Change: the base-id choice moves to
helpers.assist_base_session_id. When both a signed-in user and a conversation id are present, the key isassist_user_<id>:<conversation>: still one session per conversation, as today, and the agent can now see the speaker. A follow-up turn that hands back a key already carrying the user is kept as is, so it is never prefixed twice. Without a user the order is unchanged (conversation id, then device, thenassist_default). The "Assist session ID override" still wins when set, and agent scoping is unchanged. README: one line under "Model selection" describes the key.Tests: added
AssistBaseSessionIdTests(7 cases, including a scoped follow-up round trip);python -m unittest discover -s tests -vpasses (16 tests), plus the Python syntax check andnode --checkfrom the validate workflow.