mirror of
https://github.com/ruvnet/RuView
synced 2026-07-20 17:03:24 +00:00
ruv
0328b2c991
Root cause #5 of state_messages_published_on_snapshot_broadcast (the real one, found by reading the diag dump from636ca7b52). 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 in636ca7b52: [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>