[FIXED] MQTT: QoS2 message released on a resumed session lost its QoS and PI (#8414)
This came up while testing with
https://github.com/ConnectEverything/mqtt-test/pull/4
Two root causes. The delivery callbacks and the retain handling read the
publishing connection’s c.mqtt.pp — the last PUBLISH parsed — which is
stale for a PUBREL- or will-initiated delivery, so a QoS2 message
released after a reconnect was delivered as QoS0 with no packet
identifier. And the staged copy in $MQTT_qos2in never persisted the
retain flag, so it could not be recovered on another connection at all.
Same-connection flows worked only while the scratch happened to still
hold the right packet. Because of the interplay, the two must be fixed
together.
The delivered message now becomes the client’s current publish for the
duration of the broadcast (swapped into the readLoop-owned c.mqtt.pp,
restored by the same defer as the pubargs); wills build their own
mqttPublish and use the common path instead of writing into the scratch
by hand. The staged copy
persists the retain flag in a second, flags byte of the Nmqtt-Pub header
value, restored when the PUBREL rebuilds the publish; older servers read
only the first (QoS) byte, and messages without a flags byte read as not
retained.
Retained QoS2 messages now survive an in-flight reconnect: a PUBLISH
staged on one connection and released by the PUBREL on the next stores
the retained message, where before the retain bit died with the first
connection’s parser state. This matches Spec [MQTT-4.3.3] Method A as
implemented by mosquitto, which likewise persists the retain flag with
the staged message and applies it at release, together with the
delivery.
Added regression tests: a PUBREL on a resumed session delivers at the
subscription’s QoS exactly once, a retransmitted PUBREL is acknowledged
without redelivering, and the retain flag survives the staging round
trip.