You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a QoS 2 PUBLISH is received, the message is stored internally, and a PUBREC is sent. Once the broker receives PUBREC, message ownership is transferred to the client.
When the client receives a subsequent PUBREL, the on_message(..) callback is executed. If on_message(..) completes successfully or a manual acknowledgment is performed, a PUBCOMP is sent.
Problem
If the client disconnects and reconnects, the broker has already sent PUBREC and cannot resend the PUBLISH. If a new client instance is created instead, the broker still cannot resend the PUBLISH, causing message loss.
For the broker, a reconnection and a new client instance are indistinguishable. However, the client can differentiate between them based on session state. These scenarios should be handled separately.
Expected Behavior
The client should adhere to the message delivery retry specification. This requires retaining the following information after a connection loss:
Unacknowledged PUBLISH: If a PUBLISH has been received and passed to the handler but is not yet acknowledged, it must be reprocessed if the client restarts.
Outgoing PUBREC Packets: If a PUBREC has been sent, the message was already acknowledged and must not be reprocessed. Otherwise, this would violate the exactly-once guarantee.
Advantages
This approach ensures that events can react to PUBREL appropriately, such as committing processed data.
Messages will be properly retransmitted, and with a commit mechanism or PUBREL, no messages should be lost.
Additionally, clients can distinguish between:
Recoverable errors: Resolvable by reconnection. The message should not be reprocessed.
Application errors: Require a new client instance. The message should be reprocessed.
Note
Under this logic, the PUBLISH message itself is not part of the session state. Instead, handle_publish should dispatch the message to the handler and retain only the message ID.
Bug Description
Current Situation
When a QoS 2
PUBLISH
is received, the message is stored internally, and aPUBREC
is sent. Once the broker receivesPUBREC
, message ownership is transferred to the client.When the client receives a subsequent
PUBREL
, theon_message(..)
callback is executed. Ifon_message(..)
completes successfully or a manual acknowledgment is performed, aPUBCOMP
is sent.Problem
If the client disconnects and reconnects, the broker has already sent
PUBREC
and cannot resend thePUBLISH
. If a new client instance is created instead, the broker still cannot resend thePUBLISH
, causing message loss.For the broker, a reconnection and a new client instance are indistinguishable. However, the client can differentiate between them based on session state. These scenarios should be handled separately.
Expected Behavior
The client should adhere to the message delivery retry specification. This requires retaining the following information after a connection loss:
PUBLISH
has been received and passed to the handler but is not yet acknowledged, it must be reprocessed if the client restarts.PUBREC
Packets: If aPUBREC
has been sent, the message was already acknowledged and must not be reprocessed. Otherwise, this would violate the exactly-once guarantee.Advantages
This approach ensures that events can react to
PUBREL
appropriately, such as committing processed data.Messages will be properly retransmitted, and with a commit mechanism or
PUBREL
, no messages should be lost.Additionally, clients can distinguish between:
Note
Under this logic, the
PUBLISH
message itself is not part of the session state. Instead,handle_publish
should dispatch the message to the handler and retain only the message ID.Reproduction
This is the log:
that is generated by this example:
The
docker-compose.yml
:The
mosquitto.conf
:Environment
Logs
For many issues, especially when you cannot provide code to replicate the issue, it's helpful to include logs. Please
consider including:
The text was updated successfully, but these errors were encountered: