[nsleigh]

Summary

UptimeKuma.metrics() parses the Prometheus response (text_string_to_metric_families) and builds the UptimeKumaMonitor models directly on the event loop. That work is CPU-bound and grows with the number of monitors, so on a larger Kuma instance it can block the caller's event loop. In Home Assistant this shows up as the whole instance freezing, with unrelated integrations logging "took longer than the scheduled update interval" at the same moment (home-assistant/core#178608).

This PR moves the parsing into a module-level _parse_metrics() helper and runs it with asyncio.to_thread. The HTTP request and error handling stay on the loop. The public API and return values don't change, and self.version is still updated when app_version is present.

Changes

• pythonkuma/uptimekuma.py: parsing and model building moved into _parse_metrics(text), which returns (version, monitors). metrics() awaits it via asyncio.to_thread. UptimeKumaParseException is still raised on invalid input.
• tests/test_metrics.py: new test checking that the parser runs on a worker thread, not the event-loop thread.

Related: home-assistant/core#178608

🤖 Generated with Claude Code

[nsleigh]

Closing: testing on a live instance showed that moving the parse off the event loop doesn't fix the freeze reported in home-assistant/core#178608 (polls took ~0.1s; the stall happened during entity setup). I'll revisit when I have more time.