Repository navigation
fix(mqtt): let a reconnect follow the previous handshake instead of a fixed 15 s - #96
Merged
agessaman merged 3 commits intoNov 12, 2026
Merged
Conversation
… fixed 15 s After a link outage every slot is due at once, but reconnects were spaced by the 15 s cross-slot guard, so a five-slot node took about a minute to recover against about 16 s at boot. A reconnect may now start once the handshake that armed the guard (a first setup or another reconnect) is over and 2 s have passed, the rule first setups already use. Renewals, reconfigures and breaker probes keep the full guard, and it still expires at 15 s for a handshake that hangs.
…attempt The early release trusts the armer's pending flag, which carries no attempt identity: the outcome of an older attempt could clear it for a reconnect that was just accepted. Such a reconnect now arms the guard without an armer, so the next slot waits the full 15 s as before. Comments updated to match.
… owed A soft disconnect that times out leaves the old session's DISCONNECTED to arrive later. If a reconnect was accepted first, that event cleared the new attempt's pending flag, and the guard could release while its handshake was still running. Record the owed event per slot and arm the full 15 s guard for a reconnect issued while one is outstanding.
agessaman
marked this pull request as ready for review
November 12, 2026 03:42
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft until the source review is back.
What changes
After a link outage every slot is due to reconnect at once, but reconnects were spaced by the 15 s cross-slot guard, so a node took about
(slots - 1) x 15 sto recover. First setups already start as soon as the previous slot's handshake is over (2 s minimum gap). A backoff reconnect now gets the same early release when the guard was armed by a first setup or by another reconnect whose handshake has finished: connected and its status published, failed, or the slot lost its client.Unchanged:
Testing
esp_wifi_disconnect()(not in this branch). Three drops per board on the V4 and G3, two on the V3. Time from WiFi link-up to the last slot connected:Not tested