Disconnect without reconnect in rc13

Up until v2.0rc12 I sometimes had the issue with the (spurious) OutOfMemory error related to connection problems. Since updating to rc13 last week, I did not find those issues anymore, but instead had the following:

02:09:14|pipeline| ERROR |pipeline_stages:_on_mqtt_discon | MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
02:09:14|pipeline| WARNI |pipeline_stages:_on_mqtt_discon | MQTTTransportStage: disconnection was unexpected
02:09:14|pipeline| ERROR |handle_exceptio:handle_backgrou | Exception caught in background thread.  Unable to handle.
02:09:14|pipeline| ERROR |handle_exceptio:handle_backgrou | ['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n']

From then on, the connection seemed to be dead with no more messages being sent. Should this exception be handled by the user (me) or should the reconnect be done by the SDK?

[BertKleewein]

@mounir-futurefacts - I think I see the problem here (and a hole in our testing).

INFO:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: disconnected, but not virtually connected.  Not triggering reconnect timer.

Your first send_message call was causing the client to connect automatically, and that’s the way it’s supposed to work, but that code path wasn’t setting the flag that triggered the automatic reconnect logic.

You should be able to work around this by calling connect() on the client object before you start sending messages.

[lokijota]

Same here. Added the connect() call and just get sequences of the following:

MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None MQTTTransportStage: disconnection was unexpected Exception caught in background thread. Unable to handle. [‘azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n’] failed to receive on socket: [Errno 104] Connection reset by peer

This is fixed from my end. I was sending contents of CSV files and by mistake a pretty large one was left in the folder - causing the send_message to fail. A better error message would have been helpful, in any case. //hint, hint 😃