Detailed steps to reproduce the problem?

The CSOT specifications for non-tailable awaitData cursors for both timeoutMode (an unsupported feature of the Go Driver GODRIVER-2944) that

Drivers MUST NOT append a maxTimeMS field to getMore commands

The pathalogical case for allowing this is something like this:

1. User creates aggregate cursor with maxAwaitTimeMS
2. First batch returns fine
3. N-th call needs getMore
4. getMore fails with confusing server error mid-iteration (DRIVERS-2868)
5. User has already processed some documents

E.g.: https://github.com/prestonvasquez/go-playground/blob/20bdd2f9f196658727aa30fa50a4594f0d8132d5/mgd_csot_behavior_test.go#L383

Output:

2026/01/30 14:55:59 🔔 Container is ready: f43b163566cf
    mongolocal.go:352: Using v2 mongo client as requested
    mongolocal.go:352: Connected to mongolocal MongoDB V2 instance
[DEBUG] BatchCursor.Next: returning firstBatch, maxAwaitTime=200ms
[DEBUG] BatchCursor.Next: calling getMore, maxAwaitTime=200ms
    mgd_csot_behavior_test.go:414:
                Error Trace:    /Users/preston.vasquez/Developer/go-playground/mgd_csot_behavior_test.go:414
                Error:          Received unexpected error:
                                (BadValue) cannot set maxTimeMS on getMore command for a non-awaitData cursor
                Test:           TestMGD_CSOT_Aggregate_MaxAwaitTimeMS_GreaterThan_TimeoutMS
2026/01/30 14:55:59 🐳 Stopping container: f43b163566cf
2026/01/30 14:55:59 ✅ Container stopped: f43b163566cf
2026/01/30 14:55:59 🐳 Terminating container: f43b163566cf
2026/01/30 14:55:59 🚫 Container terminated: f43b163566cf
--- FAIL: TestMGD_CSOT_Aggregate_MaxAwaitTimeMS_GreaterThan_TimeoutMS (1.61s)
FAIL
exit status 1
FAIL    github.com/prestonvasquez/go-playground 2.331s

Definition of done: what must be done to consider the task complete?

History: Aggregation is peculiar because there are cases where it can be tailabe awaitData and adding maxAwaitTimeMS is legitimate. Specifically when using a pipeline with $changeStream. There is precedence in the Go Driver for checking an aggregation pipeline, specifically for an output aggregation. However, this is directly required for a validation:

Drivers MUST NOT specify a batchSize of zero in an aggregate command that includes an $out or $merge stage.

There are no such requirements for this case.

DoD: The naive solution is to just check the aggregation pipeline for $changeStream, and pipe that information to the batch cursor during operation. And then only append m axTimeMS to getMore in such cases. Alternatively, to avoid complexity, we could probably check if the response contains postBatchResumeToken. If it does, then apply the user's maxAwaitTimeMS.

The exact Go version used, with patch level:

go version go1.25.5 darwin/arm64

The exact version of the Go driver used:

master branch, release/2.4

Describe how MongoDB is set up. Local vs Hosted, version, topology, load balanced, etc.

3 node replica set via mongo orchestration

Current Mongosh Log ID: 697d31f671eef25ebe64327b
Connecting to:          mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.4.2
Using MongoDB:          8.3.0-alpha3-175-g91ad7bd
Using Mongosh:          2.4.2
mongosh 2.6.0 is available for download: https://www.mongodb.com/try/download/shell

The operating system and version (e.g. Windows 7, OSX 10.8, ...)

OSX 26.2

Security Vulnerabilities

NA