loop_start() before connect()

[jps-aldridge]

The documentation says that loop_start() can be called either before or after connect(), however this appears not to be true. Calling loop_start() after connect() seems to work fine

import paho.mqtt.client
print(paho.mqtt.__version__)

client = paho.mqtt.client.Client()

client.connect('keylimepi.lan')
client.loop_start()

mi = client.publish('test', 'testing')
mi.wait_for_publish()

client.disconnect()
client.loop_stop()

but if I call it before

import paho.mqtt.client
print(paho.mqtt.__version__)

client = paho.mqtt.client.Client()

client.loop_start()
client.connect('keylimepi.lan')

mi = client.publish('test', 'testing')
mi.wait_for_publish()

client.disconnect()
client.loop_stop()

then the message is not published and the wait_for_publish() call hangs.

This behaviour is observed with both version 1.4.0 and 1.5.1

[dachshund-digital]

The logic I use is to connect than loop. This makes sense to me, in that until you connect successfully looping serves little purpose. I also use connect_async and set a connect=true flag in the on_connect callback, so that I know when it is possible for loop to do any work.

I also call disconnect before loop_stop, since I want to let on_disconnect run. Even un_subscribe gets aborted when you do explicit unscribes and call loop_stop to fast for the broker to respond.

I don't tend to call wait_for_publish the way my code is designed, I use the on_publish call back to let my main loop know a publish was completed based on broker response.

[PierreF]

I'm not sure the message being dropped is a bug. You do a publish with QoS = 0 which is according to MQTTv3.1.1 standard:

The message is delivered according to the capabilities of the underlying network.

So in my interpretation, the library should drop the message is the connection is not yet established.

Having wait_for_publish that hang is a bug however.