Fix MutationQueue issue resulting in re-sending acknowledged writes. #559
Conversation
This file contains hidden or 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
getNextMutationBatchAfterBatchId() was not respecting highestAcknowledgedBatchId and therefore we were resending writes after the network was disabled / re-enabled as reported here: firebase/firebase-ios-sdk#772
wilhuff
approved these changes
Mar 12, 2018
| fromCache: true | ||
| }) | ||
|
|
||
| // handshake + write + close = 3 requests |
There was a problem hiding this comment.
This comment is a bit too terse. Is this happening as a result of disabling the network or something else?
If so it's weird because I would have thought when we disable the network nothing happens.
This could be a little clearer if you expected the write stream request count was 2 above and then this would show that all we did after that was close.
There was a problem hiding this comment.
Good point. Added the requestCount==2 expectation prior to close. FWIW, disabling the network sends an additional no-op write (
). I don't know the full context of that, but I assume it's intentional (so the backend knows we got all the acks and can GC state probably).
mikelehen
pushed a commit
to firebase/firebase-ios-sdk
that referenced
this pull request
Mar 12, 2018
Port of: firebase/firebase-js-sdk#559 Fixes #772 getNextMutationBatchAfterBatchId() was not respecting highestAcknowledgedBatchId and therefore we were resending writes after the network was disabled / re-enabled.
mikelehen
pushed a commit
to firebase/firebase-ios-sdk
that referenced
this pull request
Mar 12, 2018
Port of: firebase/firebase-js-sdk#559 Fixes #772 getNextMutationBatchAfterBatchId() was not respecting highestAcknowledgedBatchId and therefore we were resending writes after the network was disabled / re-enabled.
mikelehen
pushed a commit
to firebase/firebase-ios-sdk
that referenced
this pull request
Mar 12, 2018
Port of: firebase/firebase-js-sdk#559 Fixes #772 getNextMutationBatchAfterBatchId() was not respecting highestAcknowledgedBatchId and therefore we were resending writes after the network was disabled / re-enabled.
|
Changes LGTM too. Thanks for the changelog entry. |
mikelehen
added a commit
to firebase/firebase-ios-sdk
that referenced
this pull request
Mar 12, 2018
…909) Port of: firebase/firebase-js-sdk#559 Should address #772 once released. getNextMutationBatchAfterBatchId() was not respecting highestAcknowledgedBatchId and therefore we were resending writes after the network was disabled / re-enabled.
minafarid
pushed a commit
to minafarid/firebase-ios-sdk
that referenced
this pull request
Jun 6, 2018
…irebase#909) Port of: firebase/firebase-js-sdk#559 Should address firebase#772 once released. getNextMutationBatchAfterBatchId() was not respecting highestAcknowledgedBatchId and therefore we were resending writes after the network was disabled / re-enabled.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
getNextMutationBatchAfterBatchId() was not respecting highestAcknowledgedBatchId and therefore we were resending writes if they had been acknowledged but not removed (aka the held write acks case). This showed up when a user enabled / disabled the network as reported here and I've included a spec test to emulate that case: firebase/firebase-ios-sdk#772 (cc/ @gsoltis FYI).
This is the JS port which I'll port to iOS (where the issue was reported) once we're happy with the fix here.