fix: make quit work after connection loss#54
Open
foosel wants to merge 1 commit intosynman:develfrom
Open
Conversation
A connection loss (printer goes offline) would formerly be seen as "client already disconnected" and thus the mqtt client wouldn't be disconnected. However, in that specific state the mqtt client's loop_forever will continue to attempt to reconnect forever. So if we call quit after a disconnect, to close things for good, instead of actually disconnecting and ending the session, bpm will get stuck on the join as the mqtt client's loop_forever will never quit and thus the thread never end. Making sure to always call disconnect on the mqtt client (if we have it) solves this.
3 tasks
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
1 participant
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.
Ran into an issue with the Bambu Connector Plugin for OctoPrint: when losing connection to the printer (e.g. because it was powered off), bpm stayed active and then caused issues if at some later point in time the printer returned. Easy fix, just react to the disconnect from MQTT and tell bpm to disconnect. However, that then got stuck in the thread
joinand everything hung for good.So I went digging and learned a lot about paho mqtt and its
loop_forevermethod, which culminated in this fix.A connection loss (printer goes offline) would formerly be seen as "client already disconnected" by bpm and thus the mqtt client wouldn't be told to disconnect. However, in the specific state of an unexpected connection loss the mqtt client's
loop_foreverwill continue to attempt to reconnect forever. So if we callquitafter a disconnect, to close things for good, instead of actually disconnecting and ending the session, bpm will get stuck on thejoinas the mqtt client'sloop_foreverwill never quit and thus the thread never end.Making sure to always call
disconnecton the mqtt client (if we have it) solves this.I also switched to checking
self._clienthere, asself.clientalways creates a new client (is that really intentionally? It feels wrong to me).