In reconnect(), subscriptions are re-established:
|
if resub_topics and subscribed_topics: |
|
self.logger.debug("Attempting to resubscribe to previously subscribed topics.") |
|
self._subscribed_topics = [] |
|
while subscribed_topics: |
|
feed = subscribed_topics.pop() |
|
self.subscribe(feed) |
But there's a timing issue here; if the above code fails partway through re-subscribing, there's a silent failure case; witness:
# <connect, set on_message, etc.>
mqtt_client.subscribe("foo")
mqtt_client.subscribe("bar")
while True:
try:
mqtt_client.loop()
except MMQTTException:
while True:
mqtt_client.reconnect()
break
except MMQTTException:
# reconnect failed; wait a bit and try again
time.sleep(5)
In this scenario, if a reconnect happens and subscribe("foo") succeeds but "bar" throws an exception, then _subscribed_topics will merrily report ["foo"], and the next reconnection attempt will subscribe to "foo" and consider its job complete, returning control to the main loop without ever reattempting "bar".
(Moved from its original home in #252, with h/t to this comment.)
In
reconnect(), subscriptions are re-established:Adafruit_CircuitPython_MiniMQTT/adafruit_minimqtt/adafruit_minimqtt.py
Lines 970 to 975 in bf47a0e
But there's a timing issue here; if the above code fails partway through re-subscribing, there's a silent failure case; witness:
In this scenario, if a reconnect happens and
subscribe("foo")succeeds but "bar" throws an exception, then_subscribed_topicswill merrily report["foo"], and the next reconnection attempt will subscribe to "foo" and consider its job complete, returning control to the main loop without ever reattempting "bar".(Moved from its original home in #252, with h/t to this comment.)