* 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
* 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
* verify that the config in hass is not empty
* changed to use MockConfigEntry
* Update tests/components/ios/test_init.py
Co-Authored-By: Martin Hjelmare <marhje52@gmail.com>
* Update tests/components/ios/test_init.py
Co-Authored-By: Martin Hjelmare <marhje52@gmail.com>
* changed the test per suggestions
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* fixed what seems to be a typo
* added load_mock_device in common.py so it loads all the required things into the mocks
so they don't throw exceptions for mocks not being able to convert to int
* reverted change in homeassistant/components/dyson/sensor.py
added both values to the mock device (volatil and volatile)
* used coroutinemock to avoid exception
* added spec to mock to remove exception
* added the current_user return value so it doesnt throw exception
* fix the mocks so properties do not need .return_value
* fixed missing mock values that were causing exceptions
* moved patch to asynctest so no need to define m_init
* fixed black error
* replaced MagicMock with CoroutineMock to avoid exception
* added conversion to str so mock returns unique-id that doesn't throw json exception
* added non-empty config since hass throws exception when config is empty
* reordered the clearing of the closed Event so it can stay set at the end and not
leave a task waiting on close
* fixed the side effect so it returns one TimeoutError and after that success
Previously it reached the end of the single item list and threw an exception
* fixed the error. it doesn't happen on python 3.7.5 but CI is on 3.7.0
* fixed comment
* Don't write storage to disk while stopping
* rework change
* lint
* remove delay save and schedule final write at stop
* update tests
* fix test component using private methods
* cleanup
* always listen
* use stop in restore state again
* whitelist JSON exceptions for later
* review comment
* make zwave tests use mock storage
* replace asyncio.wait with asyncio.gather since wait ignores exceptions
fix for test_entity_platform so it expects the exception
* changed to log on failed domains
* discovered that this fix actually removes other uncaught exceptions
* fix in the list of ignored exceptions
* replaced a few ignores on dyson tests that work locally but fail in the CI
* two more tests that are failing on the CI and not locally
* removed assertion on multiple entries with same unique_id - replaced with log and return
reverted test_entity_platform to its original since now there is no exception thrown
* entered all the dyson tests. they all pass locally and probabilistically fail in the CI
* removed unnecessary str() for exception
* added log message for duplicate entity_id / unique_id
* removed log in case of False return value
* added exc_info
* change the use of exc_info