Broker ends up in an error state where it thinks there is an old connection while there is not.

[chemwolf6922]

We implemented a plugin that basically changes the behavior how mosquitto treats repeating client ids. The default behavior is to kick the old connection with the same client id. While in our case, we would like to keep the old one and deny the new one.
To do this, we implemented one basic auth callback and a disconnect callback. In the basic auth callback, we first check if the client id is in a hash map. If it is, the callback will return MOSQ_ERR_AUTH, otherwise the callback will add the client id to the map and return success. The disconnect callback will remove the id from the map.
And a strange thing happened: We found the broker sometimes ends up in an error state: When a client is connected, it is not in our map. The basic auth callback returns success. But mosquitto thinks the id has an old connection and decided to call the disconnect callback. Thus the newly added id is removed. In this error state, our client will not be able to communicate with the broker correctly and will crash (Due to SIGPIPE generated from the mosquitto library which we forget to catch while updating from 2.0.14 to 2.0.18, that is another topic though.) and reconnect. (At least 1 second between crash and the new connection). And we are back to the start, where mosquitto will again think there is an old connection and be locked in this error state.
We are sure that there is only one client connected at a time. Otherwise our filter in the basic auth callback will catch that and never approve the new connection.

[chemwolf6922]

The version we are using is 2.0.18. The same program use to work fine with the 2.0.14 version.