Whenever my broker rejects a Subscribe (because it was not authorized) it'll send the code 0x80 replacing the QoS in the SUBACK.
(See MQTT 3.1.1 Protocol SUBACK http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718068)
But this mqtt client does not handle SUBACK codes, it only accepts any SUBACK as a subscription confirmation.
I made a change to verify if any of the returned QoS codes is 0x80 (there can be multiple topics in the requested Subscribe) and then call the Failure Callback if there is at least one.
So, it'll be possible to have both callbacks being called when some topics are accepted and others rejected.
Also, the Failure Callback does not support any other parameter asside from an exception.
So there's no way to acquire the failed topic in the callback. But it is possible to verify the QoS codes (passed as parameter) in the success callback.
Whenever my broker rejects a Subscribe (because it was not authorized) it'll send the code 0x80 replacing the QoS in the SUBACK. (See MQTT 3.1.1 Protocol SUBACK http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718068) But this mqtt client does not handle SUBACK codes, it only accepts any SUBACK as a subscription confirmation.
I made a change to verify if any of the returned QoS codes is 0x80 (there can be multiple topics in the requested Subscribe) and then call the Failure Callback if there is at least one. So, it'll be possible to have both callbacks being called when some topics are accepted and others rejected.
Also, the Failure Callback does not support any other parameter asside from an exception. So there's no way to acquire the failed topic in the callback. But it is possible to verify the QoS codes (passed as parameter) in the success callback.
This verification is compatible with MQTT 3.1.