MQTT Adapter: Close device connection when a telemetry/event message cannot be processed.

A device publishes an event/telemetry message with QoS 1. The MQTT adapter after successfully establishing the device connection, realizes that the message cannot be processed e.g no credit available, the message limit is exceeded etc. In this case the device remains connected and keeps waiting for the PUBACK packet from the Hono.

Similar scenario is when a device publishes a telemtry/event message with QoS 2 (not supported by Hono). In this case, the device remain connected and it keep waiting for the PUBREC packet.

MQTT 3.1.1 spec (MQTT-3.3.5-2) specifies that there is no way to inform the MQTT client that the publish action is not accepted. The server must either make a positive acknowledgement or close the Network Connection.

[sophokles73]

With QoS 1 the clients wait for an ACK, as the remote side either sends an ACK, or is expected to close the connection.

At first I didn’t think that this is actually mandated by the spec but in 4.8 this seems to be actually stated as a requirment:

If the Client or Server encounters a Transient Error while processing an inbound Control Packet it MUST close the Network Connection on which it received that Control Packet [MQTT-4.8.0-2]. If a Server detects a Transient Error it SHOULD NOT disconnect or have any other effect on its interactions with any other Client.

So it seems that closing the connection on any problems we encounter processing an incoming message, actually seems to be what the spec expects us to do. In order to keep things simple I would then propose to not make this configurable (yet). If at a later time we find this helpful, we can still add it.

@kaniyan @calohmn @dejanb @ctron WDYT?

[kaniyan]

@sophokles73 👍