No ack sent on message redelivery after a reconnect

[cabsil]

Hello,

We are facing what we think to be an issue.

Here is the scenario :

• Subscribe is set with a callback, an auto reconnect and the manual ack is set to true
• A message is sent
• The callback is executed but the callback decides to not ack the message. This looks the correct way otherwise what would be the reason of a manual ack. So we assume this the correct behaviour. The reason of not acking the message is NOT related to the message but to other conditions which are met during the treatment of the message.
• On the broker, the message stays and is marked as unacked. This is also normal.
• After a timeout, the broker closes the connection
• The HiveMq Client automatically reconnects. No problem here
• The broker send the unacked message again. This is compliant with MQTT specs
• The callback is executed and the condition are now met so the callback acknowledge the message (success is true in the code below so we call publish.acknowledge())
• On the broker, the message is not acked. This is weird
• Then we enter a loop where the same message is sent over and over with no way to ack it

After investigation with Wireshark, we found out the reason. For some reason the HiveMQ Client doesn't send a puback in that case. So the broker doesn't get informed of the ack in the HiveMQ Client.

Here is the callback :

  callback(publish -> {
               onMessageReceived(publish.toString());

                boolean success = true;
                if (mqttConfiguration.getAck().getStrictMode()) {
                    try {
                        success = function.apply(new HiveMqttMessage(publish));
                    }
                    catch (Exception ex)
                    {
                        success = false;
                        log.error("Error when {} received message: {}", getIdentifier(), publish.toString());
                    }
                }
                if (success) {
                    publish.acknowledge();
                }
            })

We think this is a bug but maybe we are doing something wrong. In the second case, could you tell us how to handle our scenario ?

Regards

Christophe Absil