Configuring AMS slots ~6 times in a row would silently stop reaching
the printer, with filament colours jumping around briefly ~1 min
later. Root cause was the zombie-session watchdog from #887.
When an ams_filament_setting response took >10 s (normal under load)
the watchdog set `_ams_cmd_unanswered=1` and zeroed
`_last_ams_cmd_time` so it wouldn't re-fire on every status push.
The response handler that resets the counter required
`_last_ams_cmd_time > 0` — so when the late response arrived, the
reset path skipped it, leaving the counter armed at 1. The next
slow response on a fresh command (possibly minutes or hours later)
would take the counter to 2 and force-reconnect mid-publish — the
in-flight command got dropped, surfacing as "Cannot set AMS
filament setting: not connected" if the user retried during the
~1 min reconnect window.
Fix: drop the `_last_ams_cmd_time > 0` guard. Any
ams_filament_setting response proves the channel is alive, so the
counter must reset unconditionally. Real zombie sessions (no
responses at all for two consecutive >10 s windows) still trip the
watchdog correctly.
Regression test in test_bambu_mqtt.py drives the exact reporter
sequence: watchdog fires (clears timer, increments counter) →
late response arrives (must reset counter) → next slow response
(must only count as 1, not 2). Other 10 zombie-detection tests
still pass.
maziggy
dac6cbfe4e