Summary

This CSOT spec test seems to contradict the behaviour outlined in the language of the Change Streams section of the CSOT specification. Where the spec test seems to expect that the getMore that fails shares the timeout with the aggregate sent as part of the resume attempt, the language of the spec (quoted below) implies that the subsequent next call must perform the resume attempt. This, paired with the spec's requirement that the timeout be refreshed between next calls implies that the resume attempt should have the full timeoutMS to complete.

Quote from Change Streams section of CSOT specification:

If a next call fails with a timeout error, drivers MUST NOT invalidate the change stream. The subsequent next call MUST perform a resume attempt to establish a new change stream on the server.

In addition, the language of the Cursors section of the spec (quoted below) contradicts the Change Stream section and seems to be the what the spec test pointed out above is based on. 

Quote from Cursors section of CSOT specification:

If a resume is required for a next call on a change stream, the timeout MUST apply to the entirety of the initial getMore and all commands sent as part of the resume attempt.

Motivation

Who is the affected end user?

Driver Engineers implementing CSOT / Users who potentially make use of our drivers in different languages for different applications

How does this affect the end user?

Leads to confusion on the part of driver engineers; could potentially lead to friction when moving between different language's drivers for users who are expecting the feature to work the same across different drivers.

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

N/A: implementation requirements clarification

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

Confusion on the behaviour of a shared feature between drivers

Is this issue urgent?

Does this ticket have a required timeline? What is it?

Is this ticket required by a downstream team?

Needed by driver teams implementing CSOT; will impact how CSOT is accessed in mongosh via the Node.js driver.

Is this ticket only for tests?

Requires clarification of spec language and depending on outcome, may lead to changing of one or more tests.

Acceptance Criteria

• Solidify intended behaviour of change streams with CSOT
• Update any tests which assert on the behaviour of change streams with CSOT to match the agreed-upon change stream behaviour