Prevent log spam when WS subscribe_condition is active#172832
Prevent log spam when WS subscribe_condition is active#172832emontnemery wants to merge 2 commits into
Conversation
|
Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
There was a problem hiding this comment.
Pull request overview
This PR reduces log spam from repeated template condition evaluations (notably the WebSocket subscribe_condition command) by allowing template undefined-variable messages to be captured in tracing instead of being logged, and by forwarding those captured messages back to the WebSocket client.
Changes:
- Add opt-in trace support to record template variable errors/warnings on the active
TraceElementrather than logging them. - Update
subscribe_conditionto enable this opt-in behavior, clear traces per evaluation, and forward collected template errors to the client as anerrorslist. - Add/extend tests to verify template errors are traced/forwarded and not repeatedly logged.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
homeassistant/helpers/trace.py |
Extends TraceElement with template_error support and adds the record_template_errors() context manager + ContextVar. |
homeassistant/helpers/template/__init__.py |
Suppresses undefined-variable logging when opted-in and records the message on the active trace element instead. |
homeassistant/components/websocket_api/commands.py |
Clears trace per evaluation, opts into template-error recording for subscribe_condition, and forwards trace-recorded template errors to the client. |
tests/helpers/test_condition.py |
Adds coverage ensuring template variable issues are traced (when opted-in) and logged (when not opted-in). |
tests/components/websocket_api/test_commands.py |
Adds coverage ensuring subscribe_condition forwards template errors without generating template log spam. |
| trace_element = condition_trace[""][0] | ||
| assert trace_element._template_error == expected_template_error | ||
| assert trace_element.as_dict()["template_error"] == expected_template_error | ||
| assert (trace_element._result or {}) == expected_result |
| condition_trace = trace.trace_get(clear=False) | ||
| trace.trace_clear() | ||
| assert condition_trace[""][0]._template_error is None |
|
I tested it with a connected frontend, before the PR you see core is checking the template with a poll and spams the logs. Afterwards no log at all 👍 |
| for element in elements | ||
| if (template_error := element.template_error) is not None | ||
| ]: | ||
| new_event_data["errors"] = errors |
There was a problem hiding this comment.
"errors" looks like a new key in new_event_data. Will the frontend be adapted to consume this item?
Is it confusing to have one item with key "error" and another item with key "errors"?
There was a problem hiding this comment.
Frontend won't use the errors.
Proposed change
Prevent log spam related to template issues when WS
subscribe_conditionis active by adding trace functionality which captures template error messages.Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: