This repository has been archived by the owner on Dec 4, 2024. It is now read-only.
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.
Seems that
agent_manager.async_get_agent_info()
now returnsConfigEntry
entry_id
s instead ofentity_id
s, whileConversationAgentSelector
works withentity_id
s. This means that when we look for an agent name inagent_names
, we will lookup using anentity_id
in a dictionary withentry_id
as keys, so it will fail. To make this worse, we don't haveentry_id
s for the default agents (or I couldn't find one), so we end up with mixed key types in theagent_names
dictionary. This causes the issue described in #14.This PR modifies
_convert_agent_info_to_dict
function to check if an agent has aregistry_entry
property. If it does, we get theentity_id
from there and use that as a key. I'm not 100% confident that this is the proper fix for this issue, so I'm open to suggestions.