Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't blow up if config entries have unhashable unique IDs #109966

Merged
merged 5 commits into from
Feb 8, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add comment on when we remove the guard
emontnemery committed Feb 8, 2024
commit 52fece4572b77ccc1742b289e847b2e5c2a16f7d
1 change: 1 addition & 0 deletions homeassistant/config_entries.py
Original file line number Diff line number Diff line change
@@ -1150,6 +1150,7 @@ def __setitem__(self, entry_id: str, entry: ConfigEntry) -> None:
if entry.unique_id is not None:
unique_id_hash = entry.unique_id
# Guard against integrations using unhashable unique_id
# In HA Core 2024.9, we should remove the guard and instead fail
if not isinstance(entry.unique_id, Hashable):
unique_id_hash = str(entry.unique_id) # type: ignore[unreachable]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not load the config entry if the data is incorrect. I don't think we should try to be smart about it.

Copy link
Contributor Author

@emontnemery emontnemery Feb 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree, what's the point of that?
In my opinion, integration authors should be given some time to update the invalid unique id. It's not our users' fault that we do not validate the data and then suddenly made assumptions about the unvalidated data.

Copy link
Member

@bdraco bdraco Feb 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By making it a string we are relying on the custom component author who created it with a non string to be able to clean it up later.

I guess we are stuck with an assumption that they aren't actually using the unique id to store a list of data that they need to set up the integration. I'm not sure if it's a reasonable position to accommodate that use case as it's pretty far away from how the API is expected to be used.. This was wrong, the change is only to the index

The safest course would be to revert the original PR and give custom component authors a few months to fix their integrations but unfortunately there is already other work built on top of it There is probably too much risk to do that.

For most cases it probably works fine to stringify it and load it. It's the most user friendly option at least. Given how the frequency of issue reports this may be the way to go.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only semi-realistic risk I can come up with that seems possible is they have stored some object in the unique id that has a string representation that isn't unique but is somehow JSON serializable. That would be some type of impressive abuse of the system so it seems like a very contrived case and acceptable risk.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As example:
#109908 (comment)

Also, this is also still an issue for entity unique_ids (I found that out a few betas ago when I accidentally broke tellduslive)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joostlek I don't understand your comment, your example does not point to a case where there's a risk of duplicates

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was responding to bdraco's comment about string representation and JSON serializable

Copy link
Contributor Author

@emontnemery emontnemery Feb 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not load the config entry if the data is incorrect. I don't think we should try to be smart about it.

We discussed this in a meeting and there were more of us in favor of allowing the config entries to load (as the PR does) than to not load the config entry (as Martin suggests).

report_issue = async_suggest_report_issue(
Loading