Inconsistent implementation for MQTT 5 persistent sessions (clean_start)

[skobow]

Bug Description

I have noticed the python client uses clean_start=False for MQTT 5 connections on reconnecting if clean_start is not set by the user in the connect() method. This is caused by clean_start being optional and using MQTT_CLEAN_START_FIRST_ONLY as a default. At the same time the value for session expiry interval is not set or checked leading to possible 0 length interval. Even though this is a valid setting it is a contradictory combination as in this case no session is stored on the broker. The MQTT 5 specification defines the following for session expiry:

If the Session Expiry Interval is absent the value 0 is used. If it is set to 0, or is absent, the Session ends when the Network Connection is closed.

I don't understand the reason behind this implementation as from a user point of view it makes no sense to me. I either want persistent sessions (clean_start=False) or I don't (clean_start=True). The implementation can lead to unwanted / undefined behavior though.

This does also have implications for the broker as this potentially creates unwanted overhead. Creating persistent sessions can involve disk I/O operations as messages sent with QoS greater 0 need to get queued.

Reproduction

Connect to a broker using MQTT 5 w/0 setting clean_start in the connect method. Check connection parameters for client connection. clean_start is set to True. Do a server side disconnect and force the client (same instance) to reconnect. Check the client connect and see clean_start set to False.

Possible Solutions

From my POV there are these possible solutions ordered by favor:

1. Make clean_start non-optional and forcing the user to set a defined value
2. Set False or True to be the default value
3. Keep current logic but set sessions expiry interval to a value greater than zero

Environment

• Python version:
• Library version:
• Operating system (including version):
• MQTT server (name, version, configuration, hosting details): HiveMQ Enterprise 4.35

Logs