Fix late subscription to an already broken stream #912
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
A late subscription was not receiving already cached `records` and `keys` from streams which already had received errors. This kind of behaviour makes it hard to debug issues and make tests like `stub.disconnects.test_disconnects.TestDisconnects.test_disconnect_session_on_tx_pull_after_record` flaky. Moving the error notification to the end of the `ResultStreamObserver.subscribe` method solves this issue and it makes the events being informed in the correct order (in the subscribe method call).
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.
A late subscription was not receiving already cached
recordsandkeysfrom streams which already had received errors. This kind of behaviour makes it hard to debug issues and make tests likestub.disconnects.test_disconnects.TestDisconnects.test_disconnect_session_on_tx_pull_after_recordflaky.More details
When the you call
runin the driver, internally the driver will sendRUNandPULL, and putResultStreamObserverin theResponseHandlerto get notified of the messages coming.If there isn't any subscription to the
ResultStreamObserver(i.e.Result.then,Result.keys,Result.subscribe,for(const record of result), etc), the ResultStreamObserver will accumulate the events internally (and don't ask for more when the PULL is over).So, when you interact with the
Result, the subscription will be made and then the records, keys, summary and error accumulated will be informed to the observer created by theResult.The problem was happening because if the error arrives while the
Resultwas not subscribed yet (for instance, the iterator was not created, which was the case in the test since I create the iterator in the first next call) the other events were not informed to the Result. This way in the case of the server disconnect after the first record be received, it could happen of you didn't get this first record if you iterate too late.Solution
Moving the error notification to the end of the
ResultStreamObserver.subscribemethod solves this issue and it makes the events being informed in the correct order (in the subscribe method call).