Skip to content

Strategy resource cleanup is dead after a restart: "resources" flag never set on already_registered path #706

Description

@tykeal

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions