MQTTMessageInfo is_published() return false while message delivered

[aymeric-soubrouillard]

Context

I am new using the python version of Paho.mqtt. I am just trying to make a simple publish but i am facing a issue when using QoS 1 or 2: The message is successfully published on my localhost Mosquitto server but the client says that it has not been published and even worst, if I used publish_result.wait_for_publish() my program get stucked forever. With QoS 0, it always return true, even if the message hasn't been delivered (which is what Qos 0 is designed for) I have tried with both local & test.mosquitto.orf servers

How to reproduce

client = mqtt.Client()
client.connect("localhost", 1883)
publish_result = client.publish(topic="test", payload="Testing publish", qos=1, retain=False)
time.sleep(5)
print(publish_result.rc)
> 0
print(publish_result.is_published())
> False
publish_result.wait_for_publish() 
> stucked here for ever

Additional point

Why not add a timeout on wait_for_publish(). It's always a bad practice to be stucked for ever on a loop.

[akiross]

I am experiencing the same issue. Using paho-mqtt==1.4.0 with Python 3.7.4 on Linux.

[aymeric-soubrouillard]

Because published() is not synchronous, it return false while he is not aware of delivery that's why calling wait_for_publish() is mandatory. Apparently calling start_loop() before wait_for_publish() resolve the stucked forever problem.

Here is a working code:

client = mqtt.Client()
client.connect("localhost", 1883)
client.start_loop()
publish_result = client.publish(topic="test", payload="Testing publish", qos=1, retain=False)
time.sleep(5)
print(publish_result.rc)
> 0
print(publish_result.is_published())
> False
publish_result.wait_for_publish() 
print(publish_result.is_published())
> True

[guiklimek]

I'm experiencing the same issue, in a different context (publishing in the on_message() callback) https://github.com/eclipse/paho.mqtt.python/issues/527

[MattBrittan]

I'm going to close this because OIP's issue appears to have been that they were not starting a network loop and they reported the issue fixed (5 years ago :-) ).