Why the HiveMQ Bridge Extension does not consider max-qos when it subscribes?

Question

I have created a Thing in the AWS IoT Core and configured the client to publish or subscribe to any topic:

Open

I have downloaded the connection package. I put the client certificate and private key in the keystore. When I test the subscription to a topic with QoS 1 using MQTT-CLI, it succeeds; when I use QoS 2, it fails.

Having this tested, in the HiveMQ Bridge Extension configuration file, I set max-qos for every topic that my Bridge is subscribing to on the remote broker to 1.

However, when the HiveMQ Bridge Extension starts, it seems to connect to the remote broker well, but when adding a topic subscription, it immediately fails. How to fix this?

Answer

The HiveMQ Bridge Extension always subscribes using QoS 2; this is by design. The max setting is only for the incoming messages from the remote broker. If they have a higher QoS, it will be downgraded. The Subscribe packet that the HiveMQ Bridge Extension is sending to the remote broker will always indicate QoS 2, and by the MQTT specification, the remote broker MUST reply with a SUBACK, indicating the real QoS to the client. If a remote broker, like, for example, the AWS IoT Core as of 2025-09-17, disconnects a client after a SUBSCRIBE attempt with QoS 2, it is against the MQTT specification.