Summary

The timeoutMS is refreshed for getMore if maxAwaitTimeMS is set tests set the maxAwaitTimeMS too low to correctly check the desired behaviour. The intention of the tests is to assert that between cursor.next() calls on a tailableAwaitData cursor/change stream with timeoutMS=250 where each call blocks for 150ms (300ms) in total, the cursor/change stream does not throw a timeout error when maxAwaitTimeMS is set. In both cases, the maxTimeMS is set to 1 which leads to the server occasionally being unable to return the document quickly enough during the first getMore leading to a second getMore being sent.

Motivation

Who is the affected end user?

Driver engineers

How does this affect the end user?

Leads to confusion when figuring out CI failures

How likely is it that this problem or use case will occur?

Relatively frequent on sharded clusters.

If the problem does occur, what are the consequences and how severe are they?

Takes up engineering time figuring out flaky CI

Is this issue urgent?

No

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

Just tests.

Acceptance Criteria

Bump the maxAwaitTimeMS setting and the maxTimeMS assertion on the commandSucceded event for the getMore to be 10 instead of 1.