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.