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
Fix late subscription to an already broken stream (#912)
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.
**More details**
When the you call `run` in the driver, internally the driver will send `RUN` and `PULL`, and put `ResultStreamObserver` in the `ResponseHandler` to 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 the `Result`.
The problem was happening because if the error arrives while the `Result` was 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.subscribe` method solves this issue and it makes the events being informed in the correct order (in the subscribe method call).
0 commit comments