* 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
* Improve error logging on invalid MQTT entity state
* Explain not hanlding TpeError and ValueError
* Move length check closer to source
* use _LOGGER.exception
* Reduce overhead to validate mqtt topics
valid_topic would iterate all the chars 4x, refactor to only
do it 1x
valid_subscribe_topic would enumerate all the chars when there was
no + in the string
* check if adding a cache helps
* tweak lrus based on testing stats
* note to future maintainers
* note to future maintainers
* keep standard lru_cache size as increasing makes no material difference
* Allow Just-in-Time platform setup for mqtt
* Only forward the setup of new platforms
* Fix new platforms being setup at reload + test
* Revert not related changes
* Remove unused partial
* Address comments, only import plaforms if needed
* Apply suggestions from code review
* Add multipl platform discovery test
* Improve test
* Use a lock per platform
* Make sure MQTT is available starting mqtt_json
* Wait for mqtt client
* Sync client connect
* Simplify
* Addiitional tests async_wait_for_mqtt_client
* Improve comment waiting for mqtt
* Improve docstr
* Do not wait unless the MQTT client is in setup
* Handle entry errors during setup
* More comments - do not clear event
* Add snips and mqtt_room
* Add manual_mqtt
* Update homeassistant/components/mqtt/__init__.py
Co-authored-by: J. Nick Koston <nick@koston.org>
* Use a fixture, improve tests
* Simplify
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
* Cleanup config merging and adding defaults
* Optimize and update tests
* Do not mix entry and yaml config
* Make sure hass.data is initilized
* remove check on get_mqtt_data
* Tweaks to MQTT client
* Remove None assigment mqtt client and fix mock
* Move advanced broker settings to entry
* Add repair issue for deprecated settings
* Split CONFIG_SCHEMA
* Do not store certificate UI flags in entry
* Keep entered password in next dialog
* Do not process yaml config in flow
* Correct typo
* Add support for limited templates (no HASS access)
* Pass variables to automation triggers
* Support templates in MQTT triggers
* Spelling
* Handle trigger referenced by variables
* Raise on unsupported function in limited templates
* Validate MQTT trigger schema in MQTT device trigger
* Add trigger_variables to automation config schema
* Don't print stacktrace when setting up trigger throws
* Make pylint happy
* Add trigger_variables to variables
* Add debug prints, document limited template
* Add tests
* Validate MQTT trigger topic early when possible
* Improve valid_subscribe_topic_template
* Remove unnecessary exception re-wraps
* Preserve exception chains on re-raise
We slap "from cause" to almost all possible cases here. In some cases it
could conceivably be better to do "from None" if we really want to hide
the cause. However those should be in the minority, and "from cause"
should be an improvement over the corresponding raise without a "from"
in all cases anyway.
The only case where we raise from None here is in plex, where the
exception for an original invalid SSL cert is not the root cause for
failure to validate a newly fetched one.
Follow local convention on exception variable names if there is a
consistent one, otherwise `err` to match with majority of codebase.
* Fix mistaken re-wrap in homematicip_cloud/hap.py
Missed the difference between HmipConnectionError and
HmipcConnectionError.
* Do not hide original error on plex new cert validation error
Original is not the cause for the new one, but showing old in the
traceback is useful nevertheless.
