Some QOS 1 messages are lost when published during a disconnection

[gprpaes]

I am using an MQTT 5 client that publishes QoS 1 messages every 10 seconds. The client operates in an environment with an unreliable network, so disconnections are expected. I’ve observed that when a network disconnection occurs, not all messages are delivered to AWS IoT Core.

Specifically, messages published around the disconnection time are often lost and never arrive at the broker. However, messages generated during the period of disconnection are successfully queued by the SDK and delivered once the connection is re-established. My client is configured with session_expiry_interval=1200 and session_behavior=REJOIN_ALWAYS, so the session should persist across reconnects.

Has anyone else experienced this behavior? Is this a limitation or bug in the SDK, or is there something I might be missing in my configuration or usage? Any insights or suggestions would be appreciated.

[bretambrose]

What values are you configuring for ack_timeout_sec and offline_queue_behavior?

My guess is that the messages are sent, no ack is received due to disconnect and no ack timeout is set, causing them to be eternally pending. There could be an argument that there should always be a timeout by default. Such a change would alter existing behavior, but I'm not able to come up with a way that the change would worsen client behavior, and, at least in this case, it would significantly improve the default experience.

[gprpaes]

I did not set an ack_timeout_sec and the offline_queue_behavior was left as default. I will give a try setting up the ack timeout

[gprpaes]

Setting ack_timeout_sec did solve the issue, thank you very much! I would say that having a default value would definitely improve the default experience. I was thinking of the implications of not having it set by default, I don't know if understood correctly, but I am assuming that:

• There's a difference between un-acked messages as in: ClientOperationQueueBehaviorType to a message be in pending state, un-acked messages would only happen if the ack_timeout_sec is set.

• If the ack_timeout _sec is not set the message, as long as there is connectivity, is never failed as it will wait forever for the ACK. Moreover, if the message is sent by the client but is lost between client and broker in this case the message will be lost as it will be in pending.

If these assumptions are correct. I think it may be a bit confusing not having a default value, as publishing with QOS 1 I did not expect to loose data.

Thanks again for the quick reply and helping me with this issue!

[bretambrose]

I agree with your thoughts. I've created a backlog item to potentially add a default timeout and/or forbid no-timeout.