Entities remain after deletion of config entry

[bachya]

Home Assistant release with the issue:

0.79.x

Last working Home Assistant release (if known):

0.77 (possibly 0.78)

Operating environment (Hass.io/Docker/Windows/etc.):

HASS Docker image

Component/platform:

Currently exhibited in the openuv component and the simplisafe component (in dev, not yet released)

Description of problem:

In the components listed above, deleting the config entry fails to delete any entities associated with the config entry. The entities are only removed after a HASS restart

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

N/A (use config entries for both components)

Traceback (if applicable):

No immediate traceback; see below for ancillary cases.

Additional information:

Debug Tracing from SimpliSafe Component

Original source: #17148 (comment)

1. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.core] Removing entity: alarm_control_panel.1234_main_street
2. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.core] Firing event
3. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=alarm_control_panel.1234_main_street, old_state=<state alarm_control_panel.1234_main_street=disarmed; code_format=None, changed_by=None, alarm_active=False, temperature=65, friendly_name=1234 Main Street @ 2018-10-10T09:57:57.711751-06:00>, new_state=None>
4. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.4559956960] Sending {'id': 2, 'type': 'event', 'event': {'event_type': 'state_changed', 'data': {'entity_id': 'alarm_control_panel.1234_main_street', 'old_state': <state alarm_control_panel.1234_main_street=disarmed; code_format=None, changed_by=None, alarm_active=False, temperature=65, friendly_name=1234 Main Street @ 2018-10-10T09:57:57.711751-06:00>, 'new_state': None}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 10, 10, 15, 58, 14, 595742, tzinfo=<UTC>), 'context': {'id': '1fb3f29315b44ed68b00afd99e2b3b17', 'user_id': None}}}
5. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.config_entries] Unload result is True
6. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.config_entries] Unload result is True
7. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.config_entries] state adjusted
8. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=alarm_control_panel.1234_main_street, old_state=None, new_state=<state alarm_control_panel.1234_main_street=disarmed; code_format=None, changed_by=None, alarm_active=False, temperature=65, friendly_name=1234 Main Street @ 2018-10-10T09:58:14.621691-06:00>>
9. 2018-10-10 09:58:14 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.4559956960] Sending {'id': 2, 'type': 'event', 'event': {'event_type': 'state_changed', 'data': {'entity_id': 'alarm_control_panel.1234_main_street', 'old_state': None, 'new_state': <state alarm_control_panel.1234_main_street=disarmed; code_format=None, changed_by=None, alarm_active=False, temperature=65, friendly_name=1234 Main Street @ 2018-10-10T09:58:14.621691-06:00>}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 10, 10, 15, 58, 14, 621708, tzinfo=<UTC>), 'context': {'id': '8442566714d3438fb7b00f58fc0a5739', 'user_id': None}}}

From what I'm reading:

• Line 1: homeassistant.core.async_remove is called with the correct entity ID.
• Lines 2-4: The state_changed event is fired (with an old_state of whatever the alarm is currently set at and a new_state of None).
• Lines 5-6: component.async_unload_entry is called twice (with the result being True both times).
• Line 7: hass.config_entries.state is set to not_loaded.
• Line 8: Another state_changed event is fired (with an old_state of None and a new_state of whatever the alarm is currently set at).

I'm not the expert on this subsystem, but it seems like there might be two areas of strangeness:

1. Should component.async_unload_entry be called twice?
2. Why does the second state change occur at the end? Does a non-None state somehow keep the entity around?

Random, Spurious Exception

At some points, removing the config entry will yield this unhandled exception:

Traceback (most recent call last):
  File "/Users/abach/.local/share/virtualenvs/home-assistant-E4Cz_ciq/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 390, in start
    resp = await self._request_handler(request)
  File "/Users/abach/.local/share/virtualenvs/home-assistant-E4Cz_ciq/lib/python3.7/site-packages/aiohttp/web_app.py", line 366, in _handle
    resp = await handler(request)
  File "/Users/abach/.local/share/virtualenvs/home-assistant-E4Cz_ciq/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 106, in impl
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/static.py", line 66, in staticresource_middleware
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/real_ip.py", line 34, in real_ip_middleware
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/ban.py", line 66, in ban_middleware
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/auth.py", line 68, in auth_middleware
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/real_ip.py", line 34, in real_ip_middleware
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/ban.py", line 66, in ban_middleware
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/auth.py", line 68, in auth_middleware
    return await handler(request)
  File "/Users/abach/Git/home-assistant/homeassistant/components/http/view.py", line 113, in handle
    result = await result
  File "/Users/abach/Git/home-assistant/homeassistant/components/config/config_entries.py", line 69, in delete
    result = await hass.config_entries.async_remove(entry_id)
  File "/Users/abach/Git/home-assistant/homeassistant/config_entries.py", line 392, in async_remove
    entity_registry.async_clear_config_entry(entry_id)
  File "/Users/abach/Git/home-assistant/homeassistant/helpers/entity_registry.py", line 254, in async_clear_config_entry
    self._async_update_entity(entity_id, config_entry_id=None)
  File "/Users/abach/Git/home-assistant/homeassistant/helpers/entity_registry.py", line 196, in _async_update_entity
    new.update_listeners.remove(ref)
ValueError: list.remove(x): x not in list

I'm uncertain what this means or what causes it (there isn't anything consistent).

CC: @balloob

[gohm44]

I am struggling with the same issue. Moreover I have decided to migrate Home Assistant from python env to docker and after i did it OpenUV is still there. I am confused. I thought that new HA and copy paste config folder without OpenUV is enough to clean it.

[bachya]

For record-keeping, @amelchio discovered that commenting out this line seems to address the issue. In his words:

the problem is that async_registry_updated does an async_schedule_update_ha_state that will update the state after the entity is actually removed, inserting the state back into the state machine. So I got the light state in the UI but I could not actually control my light.

Still need to diagnose whether this removal introduces a break somewhere else.