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

Log a warning when replacing existing config entry with same unique id #130567

Open
wants to merge 11 commits into
base: dev
Choose a base branch
from

Conversation

epenet
Copy link
Contributor

@epenet epenet commented Nov 13, 2024

Breaking change

When a config flow creates an entry with a colliding unique ID, the old entry is currently automatically removed and replaced with the new config entry.
This can lead to unexpected behavior, and is deprecated.

Proposed change

As follow-up to #130062

cc @emontnemery

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

@epenet epenet requested a review from a team as a code owner November 13, 2024 21:57
@joostlek
Copy link
Member

One case that we should properly tackle, is mobile_app. The app can re-register and this directly uses this mechanic, so if we start logging we will get a load of issues on the apps

@joostlek
Copy link
Member

I am wondering how many people activate this functionality on nightly though

@epenet
Copy link
Contributor Author

epenet commented Nov 14, 2024

I am wondering how many people activate this functionality on nightly though

That's the point... we don't want to have too many people impacted by this until we know more how many integrations this concerns.

@epenet
Copy link
Contributor Author

epenet commented Nov 15, 2024

The other possibility is to log always for core and core components (not for custom components)
If it generates too much noise we can set back to IGNORE or even revert this PR

@epenet epenet marked this pull request as draft November 15, 2024 14:32
@epenet epenet added deprecation Indicates a breaking change to happen in the future and removed code-quality labels Nov 21, 2024
@epenet epenet marked this pull request as ready for review November 21, 2024 17:03
Comment on lines 1485 to 1486
# This causes the old entry to be removed and replaced when it
# should most likely update the previous entry and abort the flow
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we be clearer?
The flow should always be aborted.
In case of manual flows, integrations should implement options, reauth, reconfigure to allow the user to change settings.
In case of non user visible flows, the integration should optionally update the existing entry before aborting.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

"exists",
core_behavior=ReportBehavior.LOG,
core_integration_behavior=ReportBehavior.LOG,
custom_integration_behavior=ReportBehavior.LOG,
Copy link
Contributor

Choose a reason for hiding this comment

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

Shuold we start with just logging core integrations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure
I would start with logging all, and we can easily adjust later if it generates too much noise

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed core deprecation Indicates a breaking change to happen in the future small-pr PRs with less than 30 lines.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants