Fix entity state stuck out-of-sync via out-of-order event delivery

[dansimau]

• Local entity state could get out of sync with Home Assistant, caused by out of order websocket message delivery due to spawning a goroutine
• Fix is to restore ordering: buffer the per-listener response channel and send sequentially from the single read loop, instead of spawning a goroutine per message
• A single FIFO sender preserves order; the buffer keeps the read loop from blocking so CallService responses still flow
• Also add a staleness guard: drop incoming updates whose LastUpdated is older than the currently held state

[chatgpt-codex-connector]

💡 Codex Review

hal/hassws/client.go

Line 369 in aabb588

responseListenerCh <- msgBytes

Avoid blocking the websocket reader on full event queues

When an automation triggered by a subscription event calls a synchronous service method (for example Light.TurnOn calls Connection.CallService at entity_light.go:64), the handler waits for a result that is delivered by this same websocket read loop. If more than eventChannelBufferSize subscription frames are already queued ahead of that result, this synchronous send blocks on the full subscription channel, so the reader can no longer read and deliver the service result and the action times out instead of completing. Preserving per-subscription order needs a queue/drainer that does not let one busy subscription stop the shared response reader.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dansimau]

Good catch — the buffered channel + sequential send preserved ordering but didn't fully decouple the reader, so a handler blocked on a synchronous CallService could still stall it once the backlog exceeded the buffer.

Fixed in 5b3bb28 with a drainer (dispatchInOrder): a goroutine pulls frames off the read-loop channel immediately into an unbounded, order-preserving queue, and a separate feeder invokes the handler in receipt order. The reader is never blocked by a slow/reentrant handler, and per-subscription order is preserved. Both SubscribeEvents and SubscribeEventsRaw use it now; the channel buffer is demoted to a small handoff/startup smoother.

Added TestReaderNotBlockedByBlockedHandler: it blocks a handler on the first event while a backlog larger than the buffer (300 > 256) piles up, then asserts a concurrent service call still completes. It fails against the previous buffer-only approach ("read loop stalled") and passes with the drainer.

[dansimau]

Follow-up: I reconsidered the drainer (63605fe) and removed it in favour of a simpler large bounded channel.

Rationale: the worst case if the event channel fills while a handler is mid-CallService is a single dropped command + a ~3s hiccup, and it's self-healing — the call times out, the handler unblocks, the backlog drains, and the late reply is swallowed by the existing recover(). No crash, no lost events, no state corruption. It also requires a burst larger than the buffer within the 3s call timeout to occur at all.

Since a chan []byte buffer only preallocates slice headers, sizing it generously (256 → 8192) is cheap and pushes that probability to ~zero, without the drainer goroutine + unbounded mutex/cond queue. SubscribeEvents/SubscribeEventsRaw consume the channel directly again (single consumer + FIFO channel still preserves order). The out-of-order-state fix is unaffected — that comes from the sequential send + the staleness guard in StateChangeEvent, both unchanged.

Net: -118 lines vs the drainer version. I dropped TestReaderNotBlockedByBlockedHandler since it asserted a hard "reader never stalls" guarantee we're intentionally no longer making.