Are QOS1 messages failed by timeout before a disconnection is detected queued for retry?

[gprpaes]

When using the SDK if I attempt to publish a QoS 1 message and the publish operation fails due to a timeout (but before the client detects a disconnection), is that message queued for retry after reconnection, or is it dropped?

Currently, I am seeing the following behaviour on a MQTT client whenever the connection is intermittent. Some publish messages will throw AWS_ERROR_MQTT_TIMEOUT, after a while the client will fail the ping request with AWS_ERROR_PING_RESPONSE_TIMEOUT. Then, an AWS_IO_SOCKET_CLOSED is thrown.

When the above situation happens this results in messages not being received on the broker (the ones that timed out it seems).

My client has the following configs:

ack_timeout_sec=90
session_expiry_interval=1200
session_behavior=REJOIN_ALWAYS
offiline_queue_behavior=FAIL_QOS0_PUBLISH_ON_DISCONNECT

I am using MQTT5

[bretambrose]

When an operation has been failed, it will not be retried under any circumstances. Marking failure represents a terminal state.

[gprpaes]

Doesn't that mean that a QOS 1 message might not get delivered?

[bretambrose]

Sure, but that's the price you pay if you want an external operation timeout that works outside the protocol. If you want an operation timeout (for the cases where server or network issues lead to no response; for example, under certain circumstances, IoT Core will not respond to QoS 1 publishes) but don't want this behavior, make it longer than the 1.5 * Keep Alive value.

Ultimately QoS 1 is just a value that leads to specific behavior within the protocol; it's not an ironclad contract for the client.