SDK is not trying to reconnect if a publish was not successful

[jakob-sturm]

Discussed in #607

^{Originally posted by jakob-sturm January 31, 2025}
Hi,

I have the following setup:
MQTT: 3.1.1
KeepAlive: 20 minutes
QoS: 1

Now when my connection has changed under the hood (for example the modem switched carrier, but was offline for only a few seconds) and I want to publish a message, the message doesn't go through. That's fine, but it takes up to 20 minutes or longer (I guess due to the KeepAlive interval) until the SDK recognises that the connection was interrupted. Then it immediately is able to resume the connection and deliver the message. Why does it take so long and can I configure the SDK somehow to detect interrupted connections earlier and reconnect faster?

[bretambrose]

A change like that can only reliably be detected via a timeout. The two timeouts available to you are MQTT keep alive (which you've set to 20 minutes) and TCP keep alive (off by default) which is more complicated to set (https://github.com/awslabs/aws-crt-python/blob/main/awscrt/io.py#L216-L224 followed by https://github.com/awslabs/aws-crt-python/blob/main/awscrt/mqtt5.py#L1319 followed by https://github.com/aws/aws-iot-device-sdk-python-v2/blob/main/awsiot/mqtt5_client_builder.py#L10)

[jakob-sturm]

Thanks for your response. In my case I don't want to set additional keep alives because this is consuming a lot of data if sent frequently.

I would create a workaround now which would be setting a timeout (like 30s) in the future of a publish. When the timeout is reached, I would actively disconnect and try to connect the same connection again. Do you think that works?

[jakob-sturm]

In order to help others, this is what I found out about how the SDK is behaving. Disconnecting and connecting the existing connection object works for resuming a persistent session. However when creating a new connection object (even though cleanSession is set to False and clientId is the same), it does not resume the old connection and does not automatically resubscribe to the existing topics. This is in contrast to the documentation of persistent sessions in my opinion and is an issue in the SDK. Do you agree @bretambrose ?

[bretambrose]

No, I do not agree. Persistent sessions are a server-side construct. The client's role is to communicate the developer's desires and communicate back whether or not a persistent session was joined on CONNACK receipt. The SDK does that.

MQTT clients are under no obligation to re-subscribe to previously-subscribed-to topic filters should you fail to resume a session and I would argue that while seemingly a good idea, it is actually not.

[jakob-sturm]

I understand but can you explain why the server (AWS IoT Core) does not let me resume the connection when creating a new connection object while letting me resume it when using the old connection object? Can you reproduce that?

[sbSteveK]

"However when creating a new connection object (even though cleanSession is set to False and clientId is the same), it does not resume the old connection and does not automatically resubscribe to the existing topics. This is in contrast to the documentation of persistent sessions in my opinion and is an issue in the SDK."

On a disconnection and reconnection using the same connection object, the callback set during a subscribe() will be called whenever a publish is received on that subject.

When creating a NEW connection however, the callback set during a subscribe() is no longer available as its scope was within the original connection object. When reconnecting, the broker is detecting the resumed session and sending the QoS1 publishes and they are being received by the MQTT client but they have no publish received callback to pass the publish along to.

The best way to handle a scenario where you will be creating new connections that need to resume sessions is to use Connection.onMessage() https://awslabs.github.io/aws-crt-python/api/mqtt.html#awscrt.mqtt.Connection.on_message

You must set a publish handler callback using onMessage() prior to instructing the client to connect.

This function on a Connection can be used to set a callback that will give you EVERY publish that the client receives. You will have to check the topic to determine what to do with the publishes on a per-message basis.

This is unfortunately the only way to make sure you do not miss any QoS 1 publishes that were sent while the client was offline and reconnecting when creating a new connection with the same client id. Even were you to subscribe to topics immediately after a new connection were established, it's possible (and likely) that the broker would have already sent the stored QoS 1 publishes before the new subscribe is sent, acked, and the new callback can be used.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.