* Add OptionsFlow helpers to get the current config entry
* Add tests
* Improve
* Add ValueError to indicate that the config entry is not available in `__init__` method
* Use a property
* Update config_entries.py
* Update config_entries.py
* Update config_entries.py
* Add a property setter for compatibility
* Add report
* Update config_flow.py
* Add tests
* Update test_config_entries.py
* Ensure entry_id is set on reauth/reconfigure flows
* Improve
* Improve
* Use report helper
* Adjust deprecation date
* Update config_entries.py
* Improve message and adjust tests
* Apply suggestions from code review
Co-authored-by: G Johansson <goran.johansson@shiftit.se>
---------
Co-authored-by: G Johansson <goran.johansson@shiftit.se>
* Raise on non-string unique id for config entry
* Add test update entry
* Fix breaking
* Add check get_entry_by_domain_and_unique_id
* Naming
* Add test
* Fix logic
* No unique id
* Fix tests
* Fixes
* Fix gardena
* Not related to this PR
* Update docstring and comment
---------
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Add config_flow helper to get config entry from context
* Simplify
* Apply to aussie_broadband
* Another example
* Rename and adjust docstring
* Simplify
* Add test
* Refactor to hide context
* Raise
* Improve coverage
* Use AttributeError
* Use ValueError
* Raise UnknownEntry
* Index config entry discovery_keys by discovery domain
* Add new signal
* Update tests
* Update homeassistant/config_entries.py
Co-authored-by: J. Nick Koston <nick@koston.org>
* Fix imports
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
* Reinitialize zeroconf discovery flow on unignore
* Adjust tests
* Improve comments
* Fix logic for updating discovery keys
* Add tests
* Use mock_config_flow helper in new config_entries test
* Add discovery_keys attribute to ConfigEntry
* Update zeroconf rediscovery
* Change type of ConfigEntry.discovery_keys
* Update tests
* Fix DiscoveryKey.from_json_dict and add tests
* Fix test
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
* Refactor config entry forwards to implictly obtain the lock instead of explictly
This is a bit of a tradeoff to not need async_late_forward_entry_setups
The downside is we can no longer detect non-awaited plastform setups
as we will always implicitly obtain the lock instead of explictly.
Note, this PR is incomplete and is only for discussion purposes
at this point
* preen
* cover
* cover
* restore check for non-awaited platform setup
* cleanup
* fix missing word
* make non-awaited test safer
* Move runtime_data deletion after unload.
Doing this before unload means we can't use, eg. the coordinator, during teardown.
* Re-order config entry on unload
* Add test
---------
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
* Report non-awaited/non-locked config entry platform forwards
Its currently possible for config entries to be reloaded while their platforms
are being forwarded if platform forwards are not awaited or done after the
config entry is setup since the lock will not be held in this case.
In https://developers.home-assistant.io/blog/2022/07/08/config_entry_forwards
we advised to await platform forwards to ensure this does not happen, however
for sleeping devices and late discovered devices, platform forwards may happen
later.
If config platform forwards are happening during setup, they should be awaited
If config entry platform forwards are not happening during setup, instead
async_late_forward_entry_setups should be used which will hold the lock to
prevent the config entry from being unloaded while its platforms are being
setup
* Report non-awaited/non-locked config entry platform forwards
Its currently possible for config entries to be reloaded while their platforms
are being forwarded if platform forwards are not awaited or done after the
config entry is setup since the lock will not be held in this case.
In https://developers.home-assistant.io/blog/2022/07/08/config_entry_forwards
we advised to await platform forwards to ensure this does not happen, however
for sleeping devices and late discovered devices, platform forwards may happen
later.
If config platform forwards are happening during setup, they should be awaited
If config entry platform forwards are not happening during setup, instead
async_late_forward_entry_setups should be used which will hold the lock to
prevent the config entry from being unloaded while its platforms are being
setup
* run with error on to find them
* cert_exp, hold lock
* cert_exp, hold lock
* shelly async_late_forward_entry_setups
* compact
* compact
* found another
* patch up mobileapp
* patch up hue tests
* patch up smartthings
* fix mqtt
* fix esphome
* zwave_js
* mqtt
* rework
* fixes
* fix mocking
* fix mocking
* do not call async_forward_entry_setup directly
* docstrings
* docstrings
* docstrings
* add comments
* doc strings
* fixed all in core, turn off strict
* coverage
* coverage
* missing
* coverage
* Small speed up to setting up integration and config entries
When profiling tests, I noticed many calls to get_running_loop. In the places
where we are already in a coro, pass the existing loop so it does not have to
be looked up. I did not do this for places were we are not in a coro since there
is risk that an integration could be doing a non-thread-safe call and its better
that the code raises when trying to fetch the running loop vs the performance
improvement for these cases.
* fix merge
* missed some
Since every flow now has to check for single config entry, change
the check to see if a config entry exists first before calling
the _support_single_config_entry_only since _support_single_config_entry_only
has to load the integration which adds up quite a bit in test runs
* Turn on thread safety checks in async_dispatcher_send
We keep seeing issues where async_dispatcher_send is called from
a thread which means we call the callback function on the other
side in the thread as well which usually leads to a crash
* Turn on thread safety checks in async_dispatcher_send
We keep seeing issues where async_dispatcher_send is called from
a thread which means we call the callback function on the other
side in the thread as well which usually leads to a crash
* adjust
* Add thread safety checks to async_create_task
Calling async_create_task from a thread almost always results in an
fast crash. Since most internals are using async_create_background_task
or other task APIs, and this is the one integrations seem to get wrong
the most, add a thread safety check here
* Add thread safety checks to async_create_task
Calling async_create_task from a thread almost always results in an
fast crash. Since most internals are using async_create_background_task
or other task APIs, and this is the one integrations seem to get wrong
the most, add a thread safety check here
* missed one
* Update homeassistant/core.py
* fix mocks
* one more internal
* more places where internal can be used
* more places where internal can be used
* more places where internal can be used
* internal one more place since this is high volume and was already eager_start
* Always reload after a succesfull reauth-flow
* Add test, fix CI failures
* Add kwarg to prevent reloading and tests
* Do not reload entry for bond if it exists
* Remove mocks on internals
* Rename kwarg to always_reload
* Update tests/components/weatherflow_cloud/test_config_flow.py
* Update tests/components/homeworks/test_config_flow.py
* Update tests/components/homeworks/test_config_flow.py
* Rename to option to reload_even_if_entry_is_unchanged
ConfigEntries.async_initialize was trigger asyncio warnings because of the CPU time
to call __setattr__ for every variable for each ConfigEntry being loaded at startup
Co-authored-by: Sid <27780930+autinerd@users.noreply.github.com>
Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com>
Co-authored-by: J. Nick Koston <nick@koston.org>
* Move setup time logging into the context manager
We were fetching the time twice but since the context
manager already has the timing, move it there
* remove log setup assertions from integration test
* tweak logging to give us better data for tracking issues
* redundant
* adjust
* preen
* fixes
* adjust
* make api change internal so nobody uses it
* coverage
* fix test
* fix more tests
* coverage
* more tests assuming internal calls
* fix more
* adjust
* adjust
* fix axis tests
* fix broadlink -- it does not call async_forward_entry_setup
* missed some
* remove useless patch
* rename, detect it both ways
* clear
* debug
* try to fix
* handle phase finishing out while paused
* where its set does not need to know its late as that is an implemenation detail of setup
* where its set does not need to know its late as that is an implemenation detail of setup
* tweak
* simplify
* reduce complexity
* revert order change as it makes review harder
* revert naming changes as it makes review harder
* improve comment
* improve debug
* late dispatch test
* test the other way as well
* Update setup.py
* Update setup.py
* Update setup.py
* simplify
* reduce
* Refactor setup time tracking to exclude time waiting on other operations
We now exclude the import time and th time waiting on
base platforms to setup from the setup times
* tweak
* tweak
* tweak
* tweak
* adjust
* fixes
* fixes
* preen
* preen
* tweak
* tweak
* adjust
* tweak
* reduce
* do not count integrtion platforms against their parent integration
* handle legacy tts platforms
* stt as well
* one more wait
* use the same pattern in all the legacy
* fix tts and stt legacy
* fix
* fix
* reduce
* preen
* entity comp does not wait for platforms
* scene blocks as well
* fix test
* test fixes
* coverage
* coverage
* coverage
* fix test
* Update tests/test_setup.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Update tests/test_setup.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Update homeassistant/setup.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* strip
* strip WAIT_PLATFORM_INTEGRATION
* strip WAIT_PLATFORM_INTEGRATION
* strip WAIT_PLATFORM_INTEGRATION
* strip WAIT_PLATFORM_INTEGRATION
* remove complexity
* Apply suggestions from code review
* no longer works that way
* fixes
* fixes
* fixes
---------
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
epenet
G Johansson
Robert Resch
Erik Montnemery
J. Nick Koston
Marc Mueller
Jake Martin
Jan-Philipp Benecke
Sid
Jan Bouwhuis
Joost Lekkerkerker