mirror of
https://github.com/esphome/esphome.git
synced 2026-07-11 09:25:34 +00:00
J. Nick Koston
ffe5db8c7d
The Phase A/B split cached `HighFrequencyLoopRequester::is_high_frequency()` once at the top of Application::loop() and reused that value at the sleep decision after Phase B. If a component calls HighFrequencyLoopRequester::start() from inside its own loop(), the cached value is stale when we pick the sleep length, so the request doesn't take effect until the next tick. Before the decoupling, the sleep decision called the function fresh at the same point in the code, so an in-loop HF request was honored immediately. This caching silently regressed that behavior. The regression matters a lot more now than it would have previously: loop_interval_ is the power-saving knob this PR was written to enable (raised multi-second values are a documented use case), so under the new freedom the worst-case HF-request latency can stretch from ~16 ms to several seconds. Re-read is_high_frequency() fresh at the sleep decision. The gate check above continues to use the cached value — there's no correctness benefit to re-reading it there, and the "one read covers the whole tick" design intent is preserved for the gate. The function is a trivial atomic-read static; a second call is cheaper than the latency it prevents. Flagged by Copilot review on application.h:728.
