MQTT streaming: Tolerate DUP PUBLISH messages on first connecting #1436
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It is quite possible that a client can receive a PUBLISH message immediately on connection and prior to a subscription given the prior establishment of a server-side session. In this case, the PUBLISH message will often have the DUP flag set. Prior to this commit, the DUP flag would cause a packet router failure given that the routing decision was being performed out of step with where the routing state is managed. This commit moves that routing logic to the correct place. A new test has been added for the use-case described above and existing coverage also validates the DUP processing.
ennru
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is quite possible that a client can receive a
PUBLISHmessage immediately on connection and before a subscription occurs given the prior establishment of a server-side session. In this case, thePUBLISHmessage will often have theDUPflag set. Prior to this PR, theDUPflag would cause a packet router failure given that the routing decision was being performed out of step with where the routing state is managed. This PR moves that routing logic to the correct place.A new test has also been added for the use-case described above along with existing coverage validating the
DUPprocessing.