mirror of
https://github.com/esphome/esphome.git
synced 2026-09-15 09:08:41 +00:00
J. Nick Koston
2785edaac8
When millis() < started_ (e.g. scheduler passes a now value slightly ahead of real millis()), the uint32_t subtraction in finish() wraps to ~4 billion. This caused warn_blocking to fire on every call since the underflowed value always exceeds the uint16_t threshold max (65535). Fix by clamping blocking_time to uint16_t max in the cold warn_blocking path. After one warning, should_warn_of_blocking() saturates the threshold to 65535 and subsequent clamped values (65535) don't exceed it. Zero cost on the hot path — the clamp is in the noinline cold function.
