Subscribe never completes (no SUBACK) for one topic after reconnect with clean session

[nadrm]

Hi,
I'm using Aws::Crt::Mqtt::MqttConnection::Subscribe (SDK version v1.32.2) to subscribe to multiple AWS IoT Core MQTT topics, for example:

$aws/things/THING_ID/jobs/get/+
$aws/things/THING_ID/shadow/get/+
$aws/things/THING_ID/shadow/name/+/get/+
[...]

Each subscription waits for its SUBACK, and subscriptions can be issued in parallel. The MqttConnection is configured to not rejoin the previous session but to start a new one. So, after a reconnect, I re-subscribe to all topics.
However, I encountered a case where one of the subscriptions ($aws/things/THING_ID/shadow/name/+/get/+) did not trigger the SUBACK callback.

Based on the logs, the subscription was initiated at 2025-06-17 15:01:06.
No SUBACK was received until shutdown, when Disconnect() was called on the Aws::Crt::Mqtt::MqttConnection.

At that point, the following error was reported:
2025-06-17 17:03:56.934 ERROR [$aws/things/THING_ID/shadow/name/+/get/+] subscribe failed with error: libaws-c-mqtt: AWS_ERROR_MQTT_CANCELLED_FOR_CLEAN_SESSION, Old requests from the previous session are cancelled, and offline requests will not be accepted.

Interestingly, all other subscriptions made in parallel succeeded and received SUBACKs normally.
At connection time, I had set the protocol operation timeout to 25000 ms, so I expected the operation to time out after 25 seconds (this discussion #661 seems to suggest so), but that didn’t happen.

Unfortunately, AWS IoT logs were not enabled at the time, and I haven't been able to reproduce the issue so far.

Questions:

1. Is it possible that a single subscription silently fails and the corresponding SUBACK is lost (never delivered to the callback)?
2. Should the Subscribe() operation time out if no SUBACK is received?
3. Would it make sense to retry the subscription if no SUBACK is received within a certain timeout? Or can an in-progress subscription block a retry on the same topic (e.g., if the request is still internally pending)?

Any clarification or guidance would be greatly appreciated.
Thanks!

[nadrm]

Just a quick update — based on the analysis on the AWS backend, it looks like that subscription triggered an error with the reason "Throttled."
Could that be the reason why the SUBACK was not received?

[bretambrose]

Likely, yes.

[bretambrose]

1. Yes, based on your followup, the server can certainly choose to drop the subscribe. Is it out-of-compliance with the MQTT spec? Yes. There are a number of behavioral details in IoT Core that fall into that category.
2. Yes, assuming the connection is open. The timeout is only measured from network write to ack receive. It won't timeout if your connection is down.
3. It won't block it, but if the connection is down it's not going to help either and will clog up the queue. There isn't a well-defined, reliable connection-stability mechanism beyond pings/keep alive (MQTT and TCP).

Beyond that, I would suggest using the MQTT5 client over the 311 client. A number of the non-compliant edge cases (ie no ack returned) are ameliorated in MQTT5 and error reporting at the protocol level is greatly improved.

Beyond that, if you have SDK logs that cover the time period you saw the behavior, we could take a look at them.

[nadrm]

Sorry for the delay in replying — I was trying to reproduce the issue so I could provide you with logs.
Unfortunately, triggering throttling in our development environment is not straightforward, but we’re working on it.

However, I spoke with AWS backend support, and they confirmed that when a subscribe request is throttled, they do not send back a response due to backward compatibility requirements.
So I do not expect an ACK or error in this case.

They also suggested switching to MQTT5, and we're currently evaluating whether that transition is feasible.

In the meantime, can I ask what I should expect when a subscription timeout occurs? Will the SubAck callback be triggered with an error?
Or will the SDK automatically retry on timeout, and I won’t get any ACK at all?

In the cases where we observed the issue, the connection was still active (we were able to both publish and receive data on non-throttled subscriptions), but we did not see any subscribe attempts on the backend.

[bretambrose]

Timeouts are not retried; in that case, the callback is invoked with an error

[nadrm]

I noticed that in the more recent versions of aws-c-mqtt, the s_schedule_timeout_task method is called for all MQTT operations in client.c (s_publish_send, s_subscribe_send, s_resubscribe_send, and s_unsubscribe_send).
However, in the version I'm currently using, this method is only called in s_unsubscribe_send and s_publish_send.

Could this be the reason why timeouts don't work for subscriptions?
Maybe I just need to update the SDK to version 1.34.0?

[bretambrose]

Seems likely.