Commit 6ffadd6
committed
fix(mqtt): route both reconnect ladders through the stopped-client guard
reconnectSlotClient() checks isStarted() and calls connect() instead of
reconnect() when the client was stopped, but only the post-NTP stale-token
path used it. The ordinary backoff ladder and the circuit-breaker probe called
slot.client->reconnect() directly, and esp_mqtt_client_reconnect() is a no-op
on a client that is not started.
Two ways in. connect() sets _started only when esp_mqtt_client_start() returns
ESP_OK while setupSlot() sets initial_connect_done unconditionally, so a start
failure under heap pressure stranded the slot. More routinely, the WiFi-drop
handler calls disconnect() on every connected slot, which clears _started —
after that the ladder issued no-ops forever and the slot never came back.
Not caught by the soaks: the log line the guard prints can only come from the
NTP path, so a stranded slot and a slot that never entered the state produce
identical logs. Observed reconnects were broker-side drops with WiFi up, which
leave the client started.
The renewal-bounce path keeps its own isStarted() branch — it needs
softDisconnect(), which the helper does not do.1 parent c0c823b commit 6ffadd6
1 file changed
Lines changed: 6 additions & 5 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2280 | 2280 | | |
2281 | 2281 | | |
2282 | 2282 | | |
2283 | | - | |
2284 | | - | |
2285 | | - | |
2286 | 2283 | | |
| 2284 | + | |
| 2285 | + | |
| 2286 | + | |
2287 | 2287 | | |
2288 | 2288 | | |
2289 | 2289 | | |
| |||
2314 | 2314 | | |
2315 | 2315 | | |
2316 | 2316 | | |
2317 | | - | |
2318 | 2317 | | |
2319 | 2318 | | |
2320 | 2319 | | |
2321 | | - | |
2322 | 2320 | | |
| 2321 | + | |
| 2322 | + | |
| 2323 | + | |
2323 | 2324 | | |
2324 | 2325 | | |
2325 | 2326 | | |
| |||
0 commit comments