MQTT SubscriptionID clash mitigation #23
Description
Subscription ID's to MQTT need to be unique. Otherwise connection is refused (or even worse, app might go into limbo, incident in Feb 7th?)
One option could be to randomize the clientId on startup but that could also lead to a situation where the broker is responsible of maintaining these sessions (depends on broker implementation). If the app starts restarting for some reason then we could in theory stress the broker with a brand new session every time and possibly DoS the broker(?)(TODO check how our broker handles this!).
We can of course limit the number of randomization f.ex by using the date as suffix, but that won't solve the problem.
See part persistent sessions:
https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/