Root cause #5 of state_messages_published_on_snapshot_broadcast (the
real one, found by reading the diag dump from 636ca7b52). The publisher
WAS publishing presence state messages correctly. The test's filter
was the bug:
.filter(|(t, _, _)| t.contains("/inttest3/presence/state"))
The actual topic is:
homeassistant/binary_sensor/wifi_densepose_inttest3/presence/state
`wifi_densepose_inttest3` is ONE path segment with an underscore
separator. There's no `/` before `inttest3`. The substring
`/inttest3/presence/state` (with leading slash) never matches.
The 4 prior surgical fixes (cargo filter, timing, client_id, subscriber
eventloop drain) all addressed *real* publisher/subscriber lifecycle
issues that were ALSO contributing — but the *primary* reason the test
saw `presence_states = []` was a stupid substring-match bug in the
test's own assertion logic.
Found by reading the diagnostic dump landed in 636ca7b52:
[diag] retain=false topic=homeassistant/binary_sensor/wifi_densepose_inttest3/presence/state payload=OFF
There it is — the publisher is publishing OFF, just like the test
expects ON/OFF. The filter just couldn't see it.
Fixed by changing the filter to look for `wifi_densepose_inttest3/
presence/state` (no leading slash, with the prefix).
This is iteration 5 of CI-debug. Lesson preserved in
[[feedback-mqtt-integration-test-patterns]]: always include the wider
subscription + the diagnostic dump on first failure of any
publisher/subscriber test. Saves the 4 wrong-hypothesis iterations.
Refs PR #778, issue #776.
Co-Authored-By: claude-flow <ruv@ruv.net>
0328b2c991