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).