Major - P3
PyMongo's change stream resume logic is broken which can result in changes being missed under some specific circumstances.
What is wrong with the resume logic?
PyMongo does not correctly cache the postBatchResumeToken included in the aggregate command-response when firstBatch is empty.
When does this become a problem?
When a change stream that was started without resumeAfter, startAfter, or startAtOperationTime resumes after a getMore that was run immediately after aaggregate returned an empty firstBatch fails. Consider the following sequence of events:
- the driver runs an aggregate command to create a change stream; lets call this instant in time T1
- the agregate command response returns an empty firstBatch
- the driver tries to iterate the change stream - since the firstBatch was empty, the driver runs a getMore to get more results from the server which fails with some resumable error
- the driver tries to resume the change stream - it has no startAfter, resumeAfter, or startAtOperationTime and it hasn't cached the postBatchResumeToken from the initial aggregate so the change stream is created without any of these options set; lets call this instant in time T2
Due to this bug, applications might miss events that occur between T1 and T2 since the resume does not have an appropriate resume token to use.
test_change_stream.TestAllScenarios.test_change_streams_change_streams_Test_consecutive_resume occasionally blocks forever causing the test suite to timeout:
Seems to be caused by the changes in