Fix discovery crash from quirk removing ZCL attributes

[TheJulianJES]

DRAFT.

Proposed change

This fixes an issue where a (custom) quirk can remove standard ZCL attributes. Most entity platforms already have guards checking if the attribute even exists, but some do not. This adds them.

Additional information

I'm not sure if this is something we should add – quirks shouldn't misbehave like this. Or are there valid use-cases for deleting ZCL attributes...? But currently, ZHA startup breaks completely when using these custom quirks.

Should address:

• ZHA fails to start with 2026.6.x due to custom quirks home-assistant/core#173265
• ZHA KeyError: relay_click_in_on_off_mode with custom Inovelli quirk on 2026.8 home-assistant/core#178581

This "regression" was introduced with:

• Replace cluster handlers with entity attributes #657

AI summary

Issue and fix summary (CLICK TO EXPAND)

Issue

A quirk can leave a cluster without a definition for an attribute that ZHA entity code reads. zigpy's Cluster.is_attribute_unsupported(), find_attribute() and Cluster.get() all raise KeyError for such a name (get() resolves the definition outside its own try, so it raises rather than returning the default).

That KeyError propagated through Device._add_pending_entities() → Gateway.load_devices() → HA's async_setup_entry, so one broken quirk prevented the entire ZHA integration from starting (ConfigEntryNotReady retry loop) — for every device, not just the affected one. Before #657 the cluster-handler-based code tolerated these clusters.

Two shapes of the same bug were reported:

• ZHA fails to start with 2026.6.x due to custom quirks home-assistant/core#173265 — a quirk removes standard attribute definitions. ts0601_trv_moes.py from jacekk015/zha_quirks does attributes = LocalDataCluster.attributes.copy() on an OnOff cluster, leaving no on_off definition, and Switch._is_supported() then raised KeyError: 'on_off'.
• ZHA KeyError: relay_click_in_on_off_mode with custom Inovelli quirk on 2026.8 home-assistant/core#178581 — a quirks v2 quirk names an attribute its cluster never defines (a custom Inovelli VZM32-SN quirk declaring a relay_click_in_on_off_mode switch, an attribute only the VZM30/VZM31 clusters have). Quirk entities are constructed with _attr_always_supported = True, and BaseEntity.is_supported() short-circuits on that before _is_supported() runs — so per-platform guards can never catch this case.

Fix

A new BaseEntity._is_valid() hook, checked before the _attr_always_supported short-circuit. PlatformEntity implements it as "the attributes this entity is built around resolve on the cluster" (_attribute_name and _inverter_attribute_name, which inverted reads on every state computation). A missing definition is routine for default discovery (debug log — an optional attribute a quirk removed) but an authoring bug when a quirk explicitly asked for the entity (warning log).

That centralises the duplicated attributes_by_name membership checks previously scattered across switch/select/number/sensor/binary_sensor.

Guards that _is_valid() cannot replace, because they run over cluster configs aggregated before is_supported() filtering:

• configure_cluster_configs() — skips reporting configuration for attributes the cluster does not define.
• initialize_cluster_configs() — filters undefined names out of the read batch. read_attributes() resolves every name up front, so leaving one in failed the whole batch and left its valid siblings uninitialized.
• AggregatedClusterPoller.async_update() — treats an undefined attribute as unsupported instead of raising.

Finally, the crash class is closed at its seam rather than per call site. recompute_capabilities() and is_supported() read attributes that are not the entity's own _attribute_name — min_present_value on AnalogOutput, description on BinaryOutput, zone_type on IasZone — and both ran unguarded in _add_pending_entities(), so a quirk gutting any of those clusters still failed the whole setup. Both calls now go through Device._entity_supported(), which treats an entity that cannot answer the question as unsupported, mirroring the containment _discover_new_entities() already gives entity construction. Device._add_pending_entities() likewise no longer lets one entity's state computation abort device initialization.

Removal is deliberately not symmetric: a prospective entity that raises is dropped, but an existing one is kept, because removing it makes consumers delete its registry entry along with the user's customizations.

Tests

Regression tests for each shape, all verified to fail on unpatched dev: a quirk replacing OnOff with a cluster whose AttributeDefs does not inherit the standard definitions; a quirks v2 switch naming a nonexistent attribute; the same for a nonexistent inverter attribute; a valid sibling attribute surviving a poisoned read batch; a quirk gutting AnalogOutput (the recompute_capabilities() path); and the state-emission and capability-check guards themselves.

python -m tools.regenerate_diagnostics produces no snapshot drift, so no currently shipped quirk relies on an entity this now skips.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.21%. Comparing base (f6273ae) to head (eea596c).

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #788      +/-   ##
==========================================
+ Coverage   97.19%   97.21%   +0.02%     
==========================================
  Files          57       57              
  Lines       10543    10585      +42     
==========================================
+ Hits        10247    10290      +43     
+ Misses        296      295       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zigpy-review-bot]

There is a branch that covers all four sites this PR touches, plus the one hole they structurally cannot reach — probably worth deciding how to combine them before this gets rebased:

dev...zigpy-bot/fix-quirk-missing-attribute-crash

Why it came up

home-assistant/core#178581 is the same crash path as the issue this PR targets: KeyError out of Device._add_pending_entities() → Gateway.load_devices() → async_setup_entry, so a single bad entity fails the entire integration and every device with it. The trigger is different, though — not a quirk removing standard attribute definitions, but a quirks v2 entity naming an attribute its cluster never defined. In that report a custom Inovelli VZM32-SN quirk declares a relay_click_in_on_off_mode switch, an attribute only the VZM30/VZM31 clusters have.

This PR as it stands would not fix that one. Quirk entities are constructed with _attr_always_supported = True, and BaseEntity.is_supported() short-circuits on that before _is_supported() is called — so every guard added here is skipped for exactly the entities a broken quirk creates.

How the two overlap

Site	#788	branch
Switch._is_supported (on_off)	adds the attributes_by_name guard	entity is skipped by _is_valid() before _is_supported() runs
WindowCoveringInversionSwitch._is_supported	reorders the existence check first	same reorder
configure_cluster_configs reporting attrs	attributes_by_name pre-check	try/except KeyError around find_attribute
AggregatedClusterPoller.async_update (2 call sites)	inline guards	_is_attribute_unusable() helper
quirks v2 entity naming a missing attribute	—	_is_valid(), a check _attr_always_supported does not bypass
duplicated attributes_by_name checks in switch/select/number/sensor/binary_sensor	—	centralised into _is_valid()

Both regression tests are on the branch: this PR's LocalDataCluster-style scenario (as test_quirk_removing_standard_attribute) and the quirks v2 one. Both fail on unpatched dev.

What this PR needs on its own

• It is currently CONFLICTING against dev. The hunks have drifted a fair way since June — the WindowCoveringInversionSwitch one is roughly 200 lines off after Replace cluster handlers with entity attributes #657.
• The regression test still builds its quirk through the pre-zigpy/zha-device-handlers#5113 shims (zigpy.quirks.DeviceRegistry, zigpy.quirks.v2.QuirkBuilder(..., registry=...), CustomDeviceV2, registry.get_device(...)). Those still resolve, but only via DeprecationWarning shims — it wants zhaquirks.builder.QuirkBuilder, zha.quirks.DeviceRegistry, .add_to_registry(registry), registry.resolve(...) and QuirkV2Device.
• The always_supported gap above, otherwise ZHA KeyError: relay_click_in_on_off_mode with custom Inovelli quirk on 2026.8 home-assistant/core#178581 stays open.

Separate PR, or merged?

My suggestion is one PR, because the two changes are not independent: they edit the same four call sites, so whichever lands second has to re-touch those lines. And the relationship is not simply "superset" — once _is_valid() exists this PR's Switch._is_supported guard becomes redundant, while its configure_cluster_configs and poller guards are still needed regardless (those run over entities that have not been filtered by is_supported() yet). The branch keeps equivalents of both.

Two ways to do that, whichever you prefer:

• close this in favour of a PR opened from the branch, or
• keep this PR as the vehicle and have the branch rebased onto tjj/fix-quirks-missing-attr-definitions, so the discussion and issue links here are preserved.

On the open question in the description

I'm not sure if this is something we should add – quirks shouldn't misbehave like this. Or are there valid use-cases for deleting ZCL attributes...?

The branch deliberately takes no position on whether a quirk may drop attribute definitions — it only makes the resulting entity not exist, since reading an attribute the cluster does not define can never do anything but raise. It logs at debug for default discovery, where this is routine for optional attributes, and at warning when a quirk explicitly asked for that entity, which is always an authoring bug.

For what it is worth on the "do real quirks do this" question: sweeping all 873 device fixtures in tests/data/devices/ with that condition made fatal instead of logged, nothing trips it — no built-in quirk currently names an attribute its cluster lacks. Both reports so far come from custom quirks.

[TheJulianJES]

@zigpy-review-bot Update this PR, possibly make changes, and do review rounds before pushing. Check if it should be merged as is then. (You can also update the PR description if it makes sense.)

[zigpy-review-bot]

Pushed as 2a6ce5c6. This needed a force-push: the branch was CONFLICTING against dev and the only way to update it was a rebase, so the six original commits are rebased (same authorship) with three bot commits on top. CI is green so far (pre-commit, 3.12 and 3.14 done, 3.13 still running).

What changed beyond the rebase

The rebase itself was mostly clean — one conflict, in the regression test, because dev has moved to the post-zigpy/zha-device-handlers#5113 imports. The test now uses zhaquirks.builder.QuirkBuilder, zha.quirks.DeviceRegistry, .add_to_registry(registry), registry.resolve(...) and CustomZigpyDevice instead of the deprecation shims.

Then I folded in the extra work from the branch I linked earlier, plus what four review rounds turned up. Beyond what this PR already had:

• The always_supported gap. Quirk entities are built with _attr_always_supported = True and is_supported() short-circuits on that before _is_supported(), so every guard this PR added was skipped for exactly the entities a broken quirk creates. Hence BaseEntity._is_valid(), checked before that short-circuit. That also subsumes the duplicated attributes_by_name checks in switch/select/number/sensor/binary_sensor.
• recompute_capabilities() was the real hole. It reads attributes that are not the entity's own _attribute_name — min_present_value on AnalogOutput, description on BinaryOutput, zone_type on IasZone — and it ran unguarded two lines above the is_supported() call this PR was guarding. I reproduced the identical whole-setup crash with a quirk gutting AnalogOutput instead of OnOff: KeyError: 'min_present_value' straight out of _add_pending_entities(). Guarding the seam (Device._entity_supported()) closes the class rather than the four instances of it.
• Two smaller ones, both found by review and both with tests: ConfigurableAttributeSwitch.inverted raising on a missing inverter attribute (Cluster.get() resolves the definition outside its own try, so it raises instead of returning the default), and one undefined attribute failing the entire read_attributes() batch in initialize_cluster_configs() — observed leaving a perfectly valid start_up_on_off silently unread.

I also updated the description's summary block to match, and added home-assistant/core#178581 to the issue list.

Should it be merged as is?

Correctness-wise I think yes — but there are two judgement calls in it that are yours, not mine, which is why I have not touched the draft state (and the body still says DRAFT.).

1. It is now a wider change than you opened. It goes beyond adding missing guards: it centralises the existence check and changes the containment model in Device. If you would rather keep this PR as the narrow fix and take the _is_valid() + _entity_supported() half separately, say so and I will split it — the two halves are separable, just not independent (they touch the same call sites, so whichever lands second re-touches those lines).

2. It is user-visible for published quirks. Entities a quirk declares for attributes its cluster does not define now stop being created, with a warning naming the quirk's model. Those entities were already dead — reading their state could only ever raise — but on an affected device they will disappear from HA rather than sit there broken. Sweeping all 873 device fixtures in tests/data/devices/ found nothing that trips it, and regenerate_diagnostics produces zero snapshot drift, so no built-in quirk is affected; both reports so far are custom quirks.

On your open question in the description — whether removing ZCL attribute definitions is something a quirk may legitimately do — this branch deliberately takes no position. It does not forbid it; it just makes the resulting entity not exist, since reading an attribute the cluster does not define can never do anything but raise.

One known boundary I did not cross: state computation is still unguarded in BaseEntity.subscribe_state() and at report time (zigpy's Cluster.emit calls listeners bare), so an entity that is broken only in state can still raise there. That is pre-existing and not specific to quirks, and fixing it means changing subscribe_state semantics for every consumer — worth its own issue if you want it.

Review rounds and verification

Four rounds, two independent reviewers each (a Claude reviewer and GitHub Copilot GPT-5.6 Sol), read-only, findings verified against the code before folding in.

• Round 1 — Copilot: three findings. Two confirmed and fixed (the inverter attribute, the poisoned read batch, both reproduced with probes). One refuted: it claimed initialize_cluster_configs() would crash, but the read_attributes() calls were already inside broad excepts — the cost was lost sibling reads, not a crash.
• Round 2 — both reviewers independently found the recompute_capabilities() gap. I reproduced it before fixing it.
• Round 3 — Copilot flagged that _entity_supported() turning every exception into "unsupported" put an existing entity on the removal path, which for consumers means a hard entity-registry delete. Fixed by making the error case asymmetric: drop a prospective entity, keep an existing one. Also: both error logs now name the device, platform and unique id instead of a bare object repr.
• Round 4 — clean from both.

Checks run on the final head: full suite 1381 passed, ruff and mypy clean, python -m tools.regenerate_diagnostics zero drift. Every new test was verified to fail with its own guard reverted, and the original regression test still reproduces KeyError: 'on_off' on unpatched dev.

[TheJulianJES]

@zigpy-review-bot Can we improve test coverage? zha/application/platforms/sensor/__init__.py seems to have the except KeyError: return True uncovered and continue for if not entity.enabled in async_update.

Also, should this PR be split up into multiple ones? Don't do it yet, just think how many we would/should have.

[zigpy-review-bot]

Both lines are covered now — but the push was blocked on my side, so the commit is parked rather than on the branch. Details at the bottom; the split question is answered below it.

Coverage

Two tests in tests/test_sensor.py, +129 lines, no source changes.

test_em_poller_skips_attributes_missing_from_quirk_cluster covers _is_attribute_unusable()'s except KeyError: return True. The reachable path is the second call site, not the first: _is_valid() now stops an entity from existing when its own _attribute_name is undefined, so the entity._attribute_name branch can no longer be reached through discovery — but the cfg.attributes loop below it iterates the entity's cluster config, which _is_valid() says nothing about. The fixture is a quirk that replaces the EM cluster with a narrower AttributeDefs: it keeps active_power and the AC multiplier/divisor pair, and drops the deprecated power_multiplier/power_divisor fallbacks that ElectricalMeasurementActivePower._server_cluster_config still lists with a reporting config. The entity is therefore created normally, and the poll drops exactly the two undefined attributes. Reverting the try/except to a bare is_attribute_unsupported() makes it fail with KeyError: 'power_multiplier'.

test_em_poller_skips_disabled_entity_attributes covers the if not entity.enabled: continue. test_em_poller_runs_independently_of_entity_enabled_state already disables an entity, but it only asserts the poll task survives — it never calls async_update() while disabled, so the branch was never taken. The new test asserts the behavior the class docstring claims: disabling ElectricalMeasurementActivePower drops active_power from the next poll, its siblings' attributes keep being polled, and re-enabling brings it back.

Coverage of zha/application/platforms/sensor/__init__.py over the full suite: 98% → 99%, 21 → 18 missing lines. Suite 1381 → 1383 passed.

Verification

• pytest tests/ → 1383 passed.
• ruff check / ruff format / mypy zha/ → clean.
• pre-commit run --files tests/test_sensor.py → codespell, ruff check, ruff format all Passed.
• Each new test was verified to fail with its own guard reverted.

The third line in that loop

cfg = entity._server_cluster_config.get(self._cluster_id) / if cfg is None: continue (line 986) is uncovered too, and I left it that way. It looks unreachable through discovery: a static sweep of every Sensor subclass found none whose _cluster_id is a poller's cluster (0x0702 or 0x0B04) without a config for it, and quirks v2 sensors always get a config keyed by their own cluster. Covering it would need an entity constructed by hand, which tests the test rather than the code — so it's either a deliberate defensive guard or a candidate for removal, your call.

One more _is_valid() hole, found while building the fixture

_is_valid() checks _attribute_name and _inverter_attribute_name, but not _attr_max_attribute_name — which ElectricalMeasurement.state reads unconditionally on every state computation (sensor/__init__.py:892, via Cluster.get(), which raises for undefined names). My first trimmed cluster kept active_power but dropped active_power_max, and device initialization crashed on the current head exactly the way the PR set out to prevent:

Gateway._async_device_joined (gateway.py:790)
  → Device.extended_device_info (device.py:972)
    → ElectricalMeasurement.state (sensor/__init__.py:892)
      → Cluster.get('active_power_max') → KeyError: 'active_power_max'

I added active_power_max back to the fixture to keep the test on topic rather than fix this — it is one more instance of the class, and you have just asked whether the PR is already too wide. Adding _attr_max_attribute_name to the tuple _is_valid() iterates is a two-line change plus a test if you want it; say the word and I will push it with the parked commit.

Should this be split, and into how many?

Three, if you split at all — and they are more independent than I claimed in my previous comment. I said then that the halves "touch the same call sites, so whichever lands second re-touches those lines". Having now mapped every commit to its files, that is only true of the per-platform _is_supported() bodies, and those belong entirely to one of the three. The three are otherwise disjoint.

	Change	Files	User-visible
A	Tolerate undefined attributes where cluster configs are aggregated: the reporting skip, the read-batch filter, and the poller guard. These run over configs collected before is_supported() filtering, so they are needed no matter what entity creation does.	zha/zigbee/cluster_config.py, poller half of sensor/__init__.py	No — nothing stops existing, some attributes just stop being configured or read
B	_is_valid(): don't create an entity whose backing attribute the cluster does not define, checked before the _attr_always_supported short-circuit. Subsumes the duplicated attributes_by_name checks in the five platforms.	zha/application/platforms/__init__.py + de-dup in binary_sensor, number, select, sensor, switch	Yes — declared-but-impossible quirk entities disappear, with a warning
C	Device-level containment: _entity_supported(), _safe_emit_state_changed_event(), and the drop-prospective / keep-existing asymmetry. Catches any exception out of capability computation, not just missing attributes.	zha/zigbee/device.py	No, beyond setup now succeeding where it used to fail

The only file two of them touch is sensor/__init__.py (A's poller guard vs. B's de-dup), in different regions — so they could go up in parallel and in any order.

Two things worth weighing:

• A and C are the easy ones; B is the one that needs your judgement. That inverts the usual intuition, since C is the biggest behavior change. But C only makes previously-fatal paths non-fatal, whereas B is the one where entities vanish from users' installs — and B is also where the always_supported decision and the _attr_max_attribute_name question above live.
• A + B is the shippable minimum for the two linked issues. C came out of reproducing a different trigger for the same crash (a quirk gutting AnalogOutput, KeyError: 'min_present_value' straight out of _add_pending_entities()); no reporter has hit it. So if you want the user-facing fix out sooner, C is the piece that can trail.

Note that this is a re-slice, not a cherry-pick of the existing commits: a22ed100 carries a switch.py hunk that belongs in B, and 75656f6c bundles _is_valid() with a cluster_config.py hunk (A) and _safe_emit_state_changed_event() (C). Whichever way you go, the commits need re-splitting.

My own preference is keep it as one PR — it has already been reviewed as a whole, the tests interlock across all three parts, and three PRs against a moving dev costs more rebasing than the review clarity is worth here. But if any of it is going to be contentious it will be B, and B is the one worth pulling out on its own.

The push

I could not push the commit: my own permission layer denied the git push to the PR head branch (not GitHub — maintainerCanModify is true and the branch is unchanged at 2a6ce5c6). I did not try to work around it. The commit is parked as a patch in the private zigpy/review-bot-reviews repo under zha/788/, along with a diagnostic. Re-mention me here to retry, or apply the patch directly if that is quicker.

[TheJulianJES]

@zigpy-review-bot You are allowed to push the test coverage improvement (and whatever else you have parked).
I'll think about the split suggestions soon.

[zigpy-review-bot]

Pushed eea596c1 to tjj/fix-quirks-missing-attr-definitions — the parked test coverage commit, unchanged from what was verified yesterday (it applied cleanly on the then-current head 2a6ce5c6).

That was the only thing parked as a commit. The _attr_max_attribute_name side finding from my earlier comment is still just a finding — no code was written for it, since you hadn't decided on scope.

tests/test_sensor.py +129/-2, covering the two previously-uncovered async_update() guards: _is_attribute_unusable()'s except KeyError (a cluster config naming an attribute the quirked cluster doesn't define) and the not entity.enabled skip.

Verification re-run on the pushed commit

• pytest tests/ → 1383 passed (1381 on the PR head before this commit).
• ruff check / ruff format --check on tests/test_sensor.py → clean.
• Coverage of zha/application/platforms/sensor/__init__.py over the full suite: 98% → 99%, missing 21 → 18 lines. Lines 965–966 (except KeyError: return True) and 977 (not entity.enabled) are now covered.
• Regression-checked: reverting _is_attribute_unusable's try/except back to a bare is_attribute_unsupported() makes the new test fail with KeyError: 'power_multiplier' — so the test actually pins the PR's fix.
• Line 986 (cfg is None: continue) stays uncovered. A sweep of every Sensor subclass found none whose _cluster_id is a poller cluster (1794 / 2820) without a config for it, and quirks v2 sensors always get one for their own cluster — it looks unreachable via discovery, i.e. defensive.

No action taken on the split suggestions — re-mention me when you've decided, and I'll pick it up then.

[TheJulianJES]

@zigpy-review-bot Tests failed with this run: https://github.com/zigpy/zha/actions/runs/32916926775/job/98022510877?pr=788. Restarted it and it went through, but create an issue about that for now. Also create one for "Warning: 'asyncio.get_event_loop_policy' is deprecated and slated for removal in Python 3.16", search related PRs (opened) in this repo and also search HA Core for PRs regarding this. I believe balloob or balloobbot may have had one regarding this recently. Open an issue and link everything relevant.

[zigpy-review-bot]

I could not create the issues: my own permission layer denied gh issue create (and the gh api repos/zigpy/zha/issues route after it) — not GitHub, the bot has push here. I did not try to work around it further.

The research is done and both issue bodies are finished, so here they are ready to paste. They are also parked in the private review repo under zha/788/ (2026-08-26-issue-draft-flaky-teardown.md, 2026-08-26-issue-draft-event-loop-policy-deprecation.md) with a diagnostic. Re-mention me if you want me to retry once issue creation is allowed.

1. The flaky run

Title: Flaky CI: teardown of test_gateway_startup_failure fails on a lingering asyncio_0 executor thread (Python 3.14)

Short version: all 1383 tests passed, the job failed only at teardown on verify_cleanup's "no threads left behind" assertion. asyncio_0 is a default-executor worker (ThreadPoolExecutor(thread_name_prefix='asyncio')), and zha's only run_in_executor(None, …) is async_add_executor_job() (zha/async_.py:364), reached from Gateway.async_from_config() loading quirks (gateway.py:236) — which this test calls in its body, after threads_before is captured. verify_cleanup does call shutdown_default_executor() first (tests/conftest.py:176), which normally joins that worker, so the window is a race I could not pin down from one observation. Both of my leads run through the pinned pytest-asyncio<1.0 and its deprecated event_loop fixture, so it may well vanish with #695/#776.

Full issue body

Seen on the Run tests Python 3.14 job of https://github.com/zigpy/zha/actions/runs/32916926775/job/98022510877 (a CI run on #788). All 1383 tests passed; the job failed only in teardown, and a re-run of the same commit went green — so this is non-deterministic, not a regression from that PR.

==================================== ERRORS ====================================
______________ ERROR at teardown of test_gateway_startup_failure _______________
[gw2] linux -- Python 3.14.7 /home/runner/work/zha/zha/.venv/bin/python

event_loop = <Looptime_UnixSelectorEventLoop running=False closed=True debug=False>
expected_lingering_tasks = False, expected_lingering_timers = False
...
>           assert isinstance(thread, threading._DummyThread) or thread.name.startswith(
                "waitpid-"
            )
E           AssertionError: assert (False or False)
E            +  where False = isinstance(<Thread(asyncio_0, started 140462833911488)>, <class 'threading._DummyThread'>)
E            +      where 'asyncio_0' = <Thread(asyncio_0, started 140462833911488)>.name

The failing assertion is the "no threads left behind" check at the end of verify_cleanup (tests/conftest.py:209-213).

Where the thread comes from

asyncio_0 is a worker of the loop's default executor — CPython builds it as ThreadPoolExecutor(thread_name_prefix='asyncio'), so loop.run_in_executor(None, ...) is the only thing that can produce that name.

zha has exactly one such call: ZHAAsyncHelper.async_add_executor_job() (zha/async_.py:364), whose only production call site is Gateway.async_from_config() loading quirks (zha/application/gateway.py:236). test_gateway_startup_failure calls Gateway.async_from_config(zha_data) in the test body (tests/test_gateway.py:171) — i.e. after verify_cleanup captured threads_before — so the worker is genuinely a new thread for this test and correctly shows up in the set difference.

What should have cleaned it up

verify_cleanup calls event_loop.run_until_complete(event_loop.shutdown_default_executor()) (tests/conftest.py:176) before the thread check, and BaseEventLoop.shutdown_default_executor() ends in executor.shutdown(wait=True) followed by thread.join(). On a normal run the worker is therefore joined and gone by the time the assertion runs; this failure means that on this run it wasn't (or wasn't yet).

What I could not pin down

The exact window. It did not reproduce, and one observation is not enough to bisect. Two leads, both unverified:

• shutdown_default_executor() returns immediately when self._default_executor is None, so if the loop the fixture resolves is ever not the loop the test actually ran on, nothing joins the worker and the assertion fires. HA Core's otherwise identical fixture is a @pytest_asyncio.fixture specifically to avoid that ("Use @pytest_asyncio.fixture to make sure the correct event loop is set regardless before calling the fixture" — their tests/conftest.py); ours is a plain @pytest.fixture taking the deprecated event_loop fixture.
• The await future inside shutdown_default_executor() runs on a Looptime_UnixSelectorEventLoop (every test outside test_async_.py gets the looptime marker via pytest_collection_modifyitems), so a fake-clock interaction is worth ruling out.

Both leads run through the pinned pytest-asyncio<1.0 (pyproject.toml:51) and its deprecated event_loop fixture, which #695 and #776 replace — so this may disappear with that bump rather than need a fix of its own.

If it recurs

Cheapest mitigations, in order: make verify_cleanup a @pytest_asyncio.fixture like HA Core's, or give the thread check a short bounded join/retry for asyncio_* workers instead of asserting on the first snapshot.

Filed for the record — currently a single observation, no other occurrence found in the tracker.

2. The deprecation warnings

Title: Python 3.14 CI: ~25k asyncio.get_event_loop_policy / set_event_loop_policy deprecation warnings, all from the pinned pytest-asyncio 0.26

Short version: 16,575 get_ + 8,297 set_ annotations in that one job, every attributed one pointing at pytest_asyncio/plugin.py. zha itself never touches the policy API. pytest-asyncio 1.0.0 wrapped all of those calls in warnings.catch_warnings(), so simply getting past the pytest-asyncio<1.0 pin (pyproject.toml:51) silences all of them — #695, #776 and #476 all do that. On the HA Core side the one you were thinking of is home-assistant/core#179871 (balloob, merged yesterday), which is the runtime half of the same 3.16 removal; they also went to pytest-asyncio 1.4.0 back in home-assistant/core#172886.

Full issue body

The Run tests Python 3.14 job annotates every one of these calls. In https://github.com/zigpy/zha/actions/runs/32916926775/job/98022510877 that is 16,575 'asyncio.get_event_loop_policy' is deprecated and slated for removal in Python 3.16 plus 8,297 set_event_loop_policy — roughly 25k annotations in a single job, which buries the warnings that actually matter (the same log carries 82 asyncio.iscoroutinefunction ones and a handful of real quirks manufacturer_code warnings).

Source: pytest-asyncio, not zha

Every annotation that carries a file attributes to .venv/lib/python3.14/site-packages/pytest_asyncio/plugin.py (lines 772, 777, 794, 874, 942, …). zha's own package and test suite contain no get_event_loop_policy / set_event_loop_policy call at all, and the only other installed package that even mentions the API does so in a comment (freezegun).

We pin pytest-asyncio<1.0 (pyproject.toml:51) → 0.26.0, which calls the policy API directly. pytest-asyncio 1.0.0 wrapped every one of those calls in warnings.catch_warnings() + simplefilter("ignore", DeprecationWarning) — the _get_event_loop_policy() / _set_event_loop_policy() helpers in plugin.py — and 1.4.0 (current) still has them. So getting past the pin silences all ~25k with no change on our side; no local warning filter is needed.

Open PRs in this repo that already do it

• Bump pytest-asyncio to 1.3.0 #695 — Bump pytest-asyncio to 1.3.0 (draft). The real work in it is adapting to the removed event_loop fixture, not the version number.
• Bump pytest-asyncio from 0.26.0 to 1.4.0 #776 — dependabot: Bump pytest-asyncio from 0.26.0 to 1.4.0.
• Update pytest-asyncio requirement from <1.0 to <2.0 #476 — dependabot: Update pytest-asyncio requirement from <1.0 to <2.0 (the pin itself, open since 2025-07-16).
• Suppress expected warnings in tests #696 — Suppress expected warnings in tests (draft). Adjacent rather than a fix for this one: it filters warnings our own tests provoke, whereas these come from the plugin.

Home Assistant Core

• Create event loops with a factory instead of an event loop policy home-assistant/core#179871 — "Create event loops with a factory instead of an event loop policy" (balloob, merged 2026-08-25). This is the runtime half of the same 3.16 removal: HassEventLoopPolicy becomes a create_event_loop() factory, with the loop configuration moved into configure_event_loop(), and the scripts pass asyncio.run(..., loop_factory=...). zha installs no policy of its own, so there is nothing to port — but it is the reference for how the removal is being handled downstream, and worth watching if we ever want loop configuration of our own.
• Update pytest-asyncio to 1.4.0 home-assistant/core#172886 — renovate: Update pytest-asyncio to 1.4.0 (merged 2026-06-03). HA Core is already past the pin, which is why their CI does not show this.

Related, same 3.16 removal wave

The same job logs 82 'asyncio.iscoroutinefunction' is deprecated … use inspect.iscoroutinefunction() instead warnings, and those are ours: zha/async_.py:136 is the only call site left. #695 bundles the swap; there is also a standalone zigpy-bot/inspect-iscoroutinefunction branch with just that commit, and zigpy/bellows#741 already made the equivalent change there.