$SYS PUBLISH counters not working for QoS 1 and 2

[promahn]

Hey, we are currently trying to find some issue in our setup regarding messages not being correctly forwarded to subscribers on a topic.

To find the issue we where trying to make use of the PUBLISH counters that can be found under $SYS/broker/publish/messages/dropped, $SYS/broker/publish/messages/received and $SYS/broker/publish/messages/sent.

However we noticed that the counters do not seem to increase.

$ mosquitto_sub -h localhost -t '$SYS/broker/publish/messages/#' -v -q 2
$SYS/broker/publish/messages/dropped 0
$SYS/broker/publish/messages/received 0
$SYS/broker/publish/messages/sent 0
^C
$ mosquitto_sub -h localhost -t '$SYS/broker/publish/messages/#' -v -q 1
$SYS/broker/publish/messages/dropped 0
$SYS/broker/publish/messages/received 0
$SYS/broker/publish/messages/sent 0
^C
$ mosquitto_sub -h localhost -t '$SYS/broker/publish/messages/#' -v -q 0
$SYS/broker/publish/messages/dropped 0
$SYS/broker/publish/messages/received 0
$SYS/broker/publish/messages/sent 0
$SYS/broker/publish/messages/sent 3
$SYS/broker/publish/messages/sent 4
$SYS/broker/publish/messages/sent 5

You can see that only when subscribing via QoS 0 the value of messages/sent increments by one meaning that only in that case the message we are receiving by subscribing is counted.

For the value of messages/received I can see that it only increments for messages published via QoS 0 and 1. Messages with QoS 2 do not increment the count.

$ mosquitto_pub -h localhost -t 'test' -m 'test' -q 0
$ mosquitto_pub -h localhost -t 'test' -m 'test' -q 1
$ mosquitto_pub -h localhost -t 'test' -m 'test' -q 2
$ mosquitto_sub -h localhost -t '$SYS/broker/publish/messages/#' -v -q 2
$SYS/broker/publish/messages/dropped 0
$SYS/broker/publish/messages/received 0
$SYS/broker/publish/messages/sent 0
$SYS/broker/publish/messages/received 2

I'm not sure about the messages/dropped counter as I was unable to easily produce a test case but we did not observe the count ever going up while we are pretty sure that we hit max_queued_messages because of the low default value in the older version.

We started with version 1.6.3 and decided to upgrade to 2.0.3 after we noticed the issue. However we can observe the same issue with the newer version.

[ralight]

Thank you, I'm surprised this hasn't been noticed before. I've pushed fixes on the fixes and 1.6.x branches, which will become part of 2.0.4 and 1.6.13.