Auto-resubscribing topics on reconnect

[jleskovar-tyro]

Describe the feature

Support for automatic topic resubscription in the event MQTT connection is lost and subsequently reconnected. Note that this would be separate to session resumption, and would be used in the event that a client session is lost by the MQTT broker

Use Case

Right now we have an "MQTT service" singleton component in our application stack that wraps the AWS v2 IoT SDK, and in particular topic subscription functionality. Even though we have sessions enabled with a large timeout - we occasionally see instances where the session cannot be resumed on reconnection, resulting in our application no longer able to process messages. Even though we could handle this at our service layer, I was thinking this is probably a common enough use case that warrants consideration of being implemented within the SDK itself

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

SDK version used

1.23.0

Environment details (OS name and version, etc.)

Android 10 OS

[bretambrose]

This has been requested before. My current view on no-session-resubscribe is that it's a feature that seems attractive on the surface, but when dug into, does not actually provide benefit in the sense that developing a correct application is not any easier than before.

The problem boils down to one question: Resubscribe can fail (and can fail repeatedly); what should the client do when its attempt to resubscribe fails?

There appear to be three basic choices, and all of them lead to an unsatisfactory outcome:

1. Ignore failure. This leads to a fundamentally incorrect application and the developer has no recourse to detect or fix the situation.
2. Retry. Retries can fail and in fact, given the way IoT Core's permission-based approach works (failed subscribe on MQTT5, closed connection on MQTT311), you could easily find yourself in failure loops.
3. Add a new error reporting pathway/callback and invoke that to signal the developer that the attempt to resubscribe failed.

1 and 2 seem unacceptable to me, which leaves 3. The problem with 3 is that the developer still needs to write a handler for the new failed-to-resubscribe error event or they will not have a correct application. But now you're back where you started before the feature, needing to write resubscribe logic for your application. Yes, that execution path is significantly less likely to happen, but correctness would still demand you handle it.

Maybe my viewpoint is an example of "perfect-is-the-enemy-of-good" reasoning, but I can't bring myself to advocate for a feature that doesn't seem to fully solve the problem.

[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.