Found while reviewing #702. Part of the umbrella issue #699 area, but not introduced by #702 — see "Pre-existing" below.
Problem
async_register_strategy_resource sets hass.data[DOMAIN]["resources"] = True only on the async_create_item branch (custom_components/keymaster/resources.py line 67). The already_registered early return (lines 48-50) does not set it:
already_registered = any(data[CONF_URL] == STRATEGY_PATH for data in resources.async_items())
if already_registered:
_LOGGER.debug("Strategy module already registered")
return
After a Home Assistant restart the strategy resource is already present in .storage/lovelace_resources, so registration short-circuits on that early return, and the flag stays False for the entire HA run.
async_cleanup_strategy_resource then bails at its guard (line 85):
if not hass_data.get("resources"):
_LOGGER.debug("Strategy module not automatically registered, skipping removal")
return
so async_delete_item is never awaited and the resource is never removed when the last keymaster entry unloads. In practice the cleanup path is effectively dead after the first restart: it can only ever fire within the same HA run in which the resource was originally created.
Verification
Confirmed with an executable probe (a throwaway pytest, since discarded), not by reading alone. With the resource pre-present in the collection to simulate a post-restart state:
async_register_strategy_resource(hass) leaves hass.data[DOMAIN]["resources"] as False.
async_cleanup_strategy_resource(hass, hass.data[DOMAIN]) returns without awaiting async_delete_item; the resource remains in the collection.
Pre-existing
This is not a regression from #702. Lines 67 and 85 are byte-identical at merge base 83a572ea (git show 83a572ea:custom_components/keymaster/resources.py). #702 only adds hass_data["resources"] = False after the delete, which is correct in itself but does not address the flag never being set on the already_registered path.
Suggested direction
Either set the flag on the already_registered path as well, or drop the in-memory flag entirely and make cleanup idempotent by keying off the presence of STRATEGY_PATH in the resource collection (guarding against removing a resource a user added manually in YAML mode, which the existing ResourceYAMLCollection branch already handles).
Found while reviewing #702. Part of the umbrella issue #699 area, but not introduced by #702 — see "Pre-existing" below.
Problem
async_register_strategy_resourcesetshass.data[DOMAIN]["resources"] = Trueonly on theasync_create_itembranch (custom_components/keymaster/resources.pyline 67). Thealready_registeredearly return (lines 48-50) does not set it:After a Home Assistant restart the strategy resource is already present in
.storage/lovelace_resources, so registration short-circuits on that early return, and the flag staysFalsefor the entire HA run.async_cleanup_strategy_resourcethen bails at its guard (line 85):so
async_delete_itemis never awaited and the resource is never removed when the last keymaster entry unloads. In practice the cleanup path is effectively dead after the first restart: it can only ever fire within the same HA run in which the resource was originally created.Verification
Confirmed with an executable probe (a throwaway pytest, since discarded), not by reading alone. With the resource pre-present in the collection to simulate a post-restart state:
async_register_strategy_resource(hass)leaveshass.data[DOMAIN]["resources"]asFalse.async_cleanup_strategy_resource(hass, hass.data[DOMAIN])returns without awaitingasync_delete_item; the resource remains in the collection.Pre-existing
This is not a regression from #702. Lines 67 and 85 are byte-identical at merge base
83a572ea(git show 83a572ea:custom_components/keymaster/resources.py). #702 only addshass_data["resources"] = Falseafter the delete, which is correct in itself but does not address the flag never being set on thealready_registeredpath.Suggested direction
Either set the flag on the
already_registeredpath as well, or drop the in-memory flag entirely and make cleanup idempotent by keying off the presence ofSTRATEGY_PATHin the resource collection (guarding against removing a resource a user added manually in YAML mode, which the existingResourceYAMLCollectionbranch already handles).