#178218 Logging crash ("Thread.__init__() not called") can freeze Core completely until manual restart (Python 3.14)

The problem

Home Assistant Core sometimes becomes completely unresponsive (no UI, no API, no automations) while Supervisor still reports it as healthy. It stays like this until I manually restart the VM/container — it does not recover on its own and the Supervisor watchdog does not restart it.

With debug logging enabled, I found the trigger: a normal log call (in my case from zeroconf, handling an incoming network packet) fails with this error:

  File "/usr/local/lib/python3.14/threading.py", line 1143, in name
    assert self._initialized, "Thread.__init__() not called"
AssertionError: Thread.__init__() not called

This means some thread in the process was not created the normal way, so Python can't get its name — and logging needs that name for every log line.

The problem snowballs from there: when this error happens, Home Assistant's own error handler tries to log it, hits the exact same error, and loops forever. This eventually crashes Home Assistant's shutdown routine too (homeassistant/util/executor.py, trying to join that same broken thread), so the shutdown never finishes properly either. The result: the event loop is closed, but a couple of background threads (a camera stream and a custom integration's websocket) are still alive and spam errors forever, so the Python process never actually exits — it just becomes a zombie that looks "running" to Supervisor/Docker but answers nothing.

This doesn't seem tied to one specific integration — I first saw the same crash triggered by the Cast integration (see linked issue below), and this time by zeroconf instead, with Cast working fine throughout. I'm running Python 3.14, so I suspect this is a Python 3.14 compatibility issue in Home Assistant's own thread/executor code rather than something integration-specific.

What version of Home Assistant Core has the issue?

core-2026.7.4

What was the last working version of Home Assistant Core?

core-2026.6.4

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Not integration-specific — reproduced once with the Cast integration involved and once with only zeroconf involved. Likely homeassistant/util/executor.py or a Python 3.14 threading incompatibility.

Link to integration documentation on our website

No response

Diagnostics information

Most recent reproduction (2026-08-05), with cast/pychromecast/zeroconf debug logging enabled:

2026-08-05 06:36:29.235 — First occurrence, triggered from a zeroconf mDNS callback attempting a DEBUG log call:

  File "src/zeroconf/_listener.py", line 202, in zeroconf._listener.AsyncListener._process_datagram_at_time
  File "/usr/local/lib/python3.14/logging/__init__.py", line 1508, in debug
    self._log(DEBUG, msg, args, **kwargs)
  File "/usr/local/lib/python3.14/logging/__init__.py", line 1663, in _log
    record = self.makeRecord(...)
  File "/usr/local/lib/python3.14/logging/__init__.py", line 355, in __init__
    self.threadName = threading.current_thread().name
  File "/usr/local/lib/python3.14/threading.py", line 1143, in name
    assert self._initialized, "Thread.__init__() not called"
AssertionError: Thread.__init__() not called

This cascades through asyncio's own exception handling, each attempt to log the previous failure hitting the same assertion:

  File "/usr/local/lib/python3.14/asyncio/base_events.py", line 1937, in call_exception_handler
    ctx.run(self._exception_handler, self, context)
  File "/usr/src/homeassistant/homeassistant/runner.py", line 238, in _async_loop_exception_handler
    logger.error(...)
  ...
  File "/usr/local/lib/python3.14/threading.py", line 1143, in name
    assert self._initialized, "Thread.__init__() not called"
AssertionError: Thread.__init__() not called

(repeats through asyncio.base_events.default_exception_handler as well, same assertion each time)

This eventually unwinds all the way up to Home Assistant's top-level runner, which attempts shutdown/cleanup:
Immediately after, with the event loop now closed but background threads still alive:

2026-08-05 06:36:29.235 ERROR (stream_worker) [root] Uncaught thread exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/stream/worker.py", line 393, in flush
    self._hass.loop.call_soon_threadsafe(...)
  File "/usr/local/lib/python3.14/asyncio/base_events.py", line 872, in call_soon_threadsafe
    self._check_closed()
  File "/usr/local/lib/python3.14/asyncio/base_events.py", line 550, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed

2026-08-05 06:36:29.277 ERROR (Thread-4 (run_forever)) [custom_components.wattpilot.utils] ... Could not 'self' execute async: Event loop is closed (builtins.RuntimeError)
2026-08-05 06:36:29.278 ERROR (Thread-4 (run_forever)) [websocket] error from callback ...: name 'default' is not defined

From this point, the log goes completely silent. No further log lines are written at all. Supervisor/Docker continued to report the container as running/healthy for the entire outage. The instance only recovered after I manually restarted the VM, roughly 2 hours later.

Note: Python version in use is 3.14 (visible in every traceback path, e.g. /usr/local/lib/python3.14/...).

I also have a similar (though not identical) occurrence from 2026-07-29 where the same "AssertionError: Thread.init() not called" cascade appeared (that time triggered from a Cast/pychromecast reconnect exception rather than zeroconf), also ending in Core going completely silent and unresponsive until a manual restart. Happy to attach both full logs if useful.

home-assistant_2026-08-05T06-43-06.583Z.log

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

I originally thought this was a Cast/pychromecast-specific bug (see home-assistant/core#176035) because that's what triggered the cascade the first time I saw it. Reproducing it again with debug logging enabled shows the trigger this time was unrelated to Cast (a zeroconf callback), with the Cast device reconnecting successfully throughout. I believe the real defect is in Home Assistant's own executor/thread handling (homeassistant/util/executor.py) combined with a Python 3.14 compatibility issue, rather than anything integration-specific — any chatty logging call from the "wrong" thread context seems able to trigger it.
I'm linking this to home-assistant/core#176035 since the first occurrence I noticed looked like that issue, but I believe this is a distinct, more fundamental bug.
Given the severity (a fully unresponsive instance that no watchdog detects), and that it appears tied to Python 3.14, it might be worth checking whether Python 3.14 is fully supported/tested for this Core release yet.