Replace the fixed asyncio.sleep(0.5) with a wait on an asyncio.Event that
fires once all thread messages have arrived over the API. Every buffered
message is delivered whether it survives intact or gets clobbered, so counting
THREADMSG occurrences is a deterministic drain-complete signal with no arbitrary
sleep and no dependence on the fix being present.
The synchronous logging path holds the main-task recursion guard around
notify_listeners_, but the buffered drain in Logger::process_messages_ did not.
When a message logged from a non-main thread was drained on the main loop and a
listener (the API log forwarder, or a logger.on_message automation) logged again
on the main task, that re-entrant log reused the shared tx_buffer_ and the API
shared_write_buffer_ while they were still in use, corrupting the in-flight
message; on ESP32 this surfaced as a StoreProhibited panic in the API send path.
Hold a RecursionGuard on main_task_recursion_guard_ across the drain so re-entrant
main-task logs are dropped there too, mirroring the synchronous path.
Adds an integration test that drives the buffered drain with a re-entrant
on_message log and verifies the buffered messages are delivered uncorrupted.
Co-authored-by: J. Nick Koston <nick@home-assistant.io>
Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
Co-authored-by: J. Nick Koston <nick@koston.org>
The fixture shares the `host-climate-test` build dir with
host_mode_climate_control.yaml. When the control test runs first and
leaves the thermostat in HEAT mode, MEMORY restore on the next basic_state
boot picked up HEAT and the initial-state assertion failed
(`assert ClimateMode.HEAT == ClimateMode.OFF`).
Adds an assertion that the observed peak pool size exceeds the old
MAX_POOL_SIZE=5 cap. Without this, a silent regression that re-introduced a
small cap could pass the existing pool_full_count == 0 invariant. Phase 5 + 6
of the fixture schedule 8 + 10 same-component timeouts, so the peak should
comfortably exceed 5.
Address Copilot review feedback on PR.
The fixed MAX_POOL_SIZE=5 cap was the source of the heap churn the pool was
meant to prevent: any device with more than 5 concurrent timers (e.g. a board
with 30+ LD2450 sensors) hit a steady-state oscillation of recycle->delete and
acquire->new on every loop iteration.
Replace std::vector<SchedulerItem*> with a singly-linked freelist threaded
through SchedulerItem::next_free, which shares storage with `component` via an
anonymous union (zero per-item overhead -- the component pointer is dead while
pooled). Drop the cap entirely: the freelist quiesces at the application's
natural concurrent-timer high-water mark, which is the working set the device
already needs while those timers are active.
No std::vector means no growth-doubling slack and no realloc copies during
warm-up. Caller of get_item_from_pool_locked_() must overwrite item->component
before unlocking (already true at the sole call site); nullptr remains a valid
live `component` value for SELF_POINTER items, so we cannot pre-clear it.
- Strip const for the %p varargs call (the format spec takes void*, not
const void*; same representation everywhere but pedantically correct).
- Mention SELF_POINTER in the NameType discriminator comment.
- Update test docstring to match the actual const void * signatures.