Mosquitto: 2.0.x Persistent Client Subscription info not considered after SIGUP to broker

Question

Bug cleaned up after investigation on (Date 20th October 2023)

Setup Details: I have a client timeSeriesPublisher acting as a publisher of Topic A. Configuration Clean Session as True, Messages sent with QOS 1 )

I have a client timeSeriesSubscriber acting as a subscriber of Topic A. Clean Session False, QOS1

1. When timeSeriesSubscriber ( which is acting as subscriber) disconnects, mosquito stores all the messages that are sent by client timeSeriesPublisher in the mosquitto.db as timeSeriesSubscriber to the message is not yet finished reading the message.

2. With timeSeriesSubscriber in disconnection state if the broker is restarted the subscription information of client timeSeriesSubscriber is found to be still remembered as the new messages from timeSeriesPublisher continued to be accumulated/stored in the mosquitto.db.

But if a SIGHUP is given to the broker after the restart the new messages from timeSeriesPublisher are found to be acknowledged but are not delivered to timeSeriesSubscriber after it returns back nor are stored in the mosquitto.db.

Reference: This behavior is found to be not in line with definition of persistent client "On connection, a client sets the "clean session" flag, which is sometimes also known as the "clean start" flag. If clean session is set to false, then the connection is treated as durable. This means that when the client disconnects, any subscriptions it has will remain and any subsequent QoS 1 or 2 messages will be stored until it connects again in the future. "

Simplified duplication Procedure: (Date 20th October 2023)

Please find the simplistic duplication procedure using mosquitto_sub, mosquitto_pub and mosquito. The script runs the broker, subscriber and publisher and restarts them in a timely fashion to create the bug.

1. Sets up the environment, files
2. Brings up broker and subscriber
3. publishes a message
4. kills the subscriber
5. Kills the broker
6. Setup broker again
7. publishes a message
8. SIGHUP broker
9. Publishes around 4 messages
10. Setup subscriber
11. Kills broker and subscriber

The messages which are expected to be received by the subscriber after it changes its state from inactive to active are lost if the SIGHUP message is given to broker. We can notice that neither subscriber received the messages nor they are stored in the db. If the step 8 is skipped then we notice that there is no issue. Script that creates the issue