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
We're experiencing infrequent incidents where it appears that the callback supplied to client.publish is not always called when QoS is set to zero.
First, am I right in assuming the callback should always be called for qos=0 - either with an error or null indicating success? The documentation would seem to indicate this but is not explicit:
callback - function (err), fired when the QoS handling completes, or at the next tick if QoS 0. An error occurs if client is disconnecting.
We think that the issue occurs when an unexpected disconnect from the broker happens at exactly the right moment - just before a call to publish but before the disconnect has been picked up by the library.
Looking at the source code, checks are made for the connection state before attempting to publish at client.js#617:
if (this._checkDisconnecting(callback)) {
return this
}
and client.js#617:
if (!this.connected) {
...
}
If these checks pass then the packet is written to client.stream and the callback is scheduled to be called on the next drain event. (client.js#180):
client.stream.once('drain', cb)
However, if the disconnect happens after the checks but before actually sending the packet there is a potential race condition where the packet is written but drain will never be fired and the callback is not called.
Can you confirm if this is a bug or we are making assumptions about the callback processing that are not valid for qos=0?
The text was updated successfully, but these errors were encountered:
This is an automated message to let you know that this issue has
gone 365 days without any activity. In order to ensure that we work
on issues that still matter, this issue will be closed in 14 days.
If this issue is still important, you can simply comment with a
"bump" to keep it open.
mqtt 4.3.7
We're experiencing infrequent incidents where it appears that the callback supplied to client.publish is not always called when QoS is set to zero.
First, am I right in assuming the callback should always be called for qos=0 - either with an error or null indicating success? The documentation would seem to indicate this but is not explicit:
We think that the issue occurs when an unexpected disconnect from the broker happens at exactly the right moment - just before a call to publish but before the disconnect has been picked up by the library.
Looking at the source code, checks are made for the connection state before attempting to publish at client.js#617:
and client.js#617:
If these checks pass then the packet is written to client.stream and the callback is scheduled to be called on the next
drain
event. (client.js#180):However, if the disconnect happens after the checks but before actually sending the packet there is a potential race condition where the packet is written but
drain
will never be fired and the callback is not called.Can you confirm if this is a bug or we are making assumptions about the callback processing that are not valid for qos=0?
The text was updated successfully, but these errors were encountered: