Subscribing to valid, but forbidden topics deadlocks lib

[mzanetti]

Trying to subscribe to e.g. "#" which at least according to awsiotsdk::mqtt::Subscription::IsValidTopicName() is a valid topic but according to the server policy my client is not authorized to subscribe to, results in no callbacks being called any more.
I could reproduce this with other topic ids too. I would have expected that the sdk would call my callback I provided on SubscribeAsync with an error code, or perhaps calls the disconnect callback or something, but it doesn't. In fact, subsequent [Publish|Subscribe]Async() calls callbacks are not called any more either until the sdk is shut down.

example log from my app with a allowed topic:

is connected true
topic to subscribe is "someallowed/topic/#" is valid topic: true
subscribe call queued with status: "Success : SDK Code 0." actionId: 2
publish call queued with status: "Success : SDK Code 0." actionId: 3
subscribeCallback for actionId 2 "Success : SDK Code 0."
publishCallback for actionId 3 "Success : SDK Code 0."
Received event from subscription: "someallowed/topic/MyNamespace.FakeMethod"

same app when trying to subscribe to something forbidden:

is connected true
topic to subscribe is "#" is valid topic: true
subscribe call queued with status: "Success : SDK Code 0." actionId: 2
publish call queued with status: "Success : SDK Code 0." actionId: 3

And that's it, I never get any callbacks called any more after this.

[vareddy-zz]

Hi @mzanetti,
'#' by itself is a valid topic and the SDK should work correctly when you subscribe to it. Are you seeing this issue when you are subscribed to multiple topics or just one topic?
Could you also provide more details about the issue that you are seeing? What MQTT broker are you using, the AWS IoT broker or some other broker, like Mosquitto? Could you also provide some of the other topics that cause the SDK to deadlock?
Also, you can check if a topic is valid by using the test page on the AWS IoT console
Thank you for using AWS IoT!
Varun

[mzanetti]

Hi, I see this issue when subscribing just to '#' as a single topic, but also when subscribing to multiple ones, like {"some/allowed/topic", "#"}. As long as one of the topic is gives an access denied, this issue happens.

I am connecting to the AWS IoT broker.

It happens with anything that is not explicitly marked as allowed in the policy... For instance, using the AWS IoT console, I can subscribe and publish to "foo/bar". But when I use the cpp-sdk, subscribing to "foo/bar" deadlocks it. During my testing I just noticed that the same happens with publishing to "foo/bar"...

[vareddy-zz]

Hi @mzanetti,
Sorry for the late reply! In my testing with the PubSub sample, when the topic you want to subscribe to is not included in the policy, it gets automatically disconnected from the broker and the disconnect callback is called. This is expected behavior. It then goes through the auto-reconnect and auto-resubscribe procedure as expected.

I am not able to reproduce the issue which you are seeing, which is a complete deadlock. Have you tried the PubSub sample with a forbidden topic to see how it behaves? It might be a problem with the threading, which could cause one of the threads to get deadlocked.
Thanks!
Varun

[vareddy-zz]

Hi @mzanetti,
We have not heard from you for a while so we are closing the issue for now. Please feel free to open up a new issue if you run into any problems with the SDK.
Thanks!
Varun

[mzanetti]

Hello, sorry for the late response. I had been busy with other stuff, now back on this topic.

Admittedly, I didn't express myself correctly. It's not a deadlock per se, however, what I mean is that the actual failing call and any subsequent calls are not handled by the library any more. Once this happens, the developer just doesn't get any feedback any more, not even errors, just nothing happens, until the connection drops, which seems to take rather long here (> 30 secs).

This makes it very hard to do error handling... For instance, our setup is made in a way where a device needs to publish something to a topic like /register/device/ in case it is not known by the system yet. This publish call would set up policies on the server to allow this device to subscribe/publish to other device specific topics (topics with the device id in it, so the policy can only be created at that point). I would have wanted to try to subscribe to such a device specific topic, and in case that fails, I'd know that the register call has still to be done.

With the current behavior of the lib that's not feasible as I don't get an error but a connection drop at some later point.

I'm not saying that there are no ways around this (in our case I guess we'll change the server to just accept repeated /register/device calls and call it on every connection just to be sure the policies are in place) but I reported this bug as this seems like a rather odd behavior for a library to me.

[vareddy-zz]

Hi @mzanetti,
Apologies for the late reply, we don't track closed issues very well.

The only way that the server let's us know that a topic isn't allowed in the policy is to disconnect immediately, which is recognized when the keepalive fails. There is no distinction between a disconnect that happens due to other reasons and a disconnect due to a disallowed topic. I admit that makes it hard to recognize the cause of the disconnection and handle it appropriately.

What you are suggesting as a workaround makes sense but I agree it makes it more tedious.
Thanks!
Varun

[mzanetti]

Ok. Thanks a lot for the clarification :)