-
Type:
Spec Change
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Component/s: CSOT
-
None
-
Needed - No Spec Changes
Summary
The CSOT spec states drivers "MUST NOT append a maxTimeMS field to getMore commands" for non-tailable cursors, but should use maxAwaitTimeMS for tailable awaitData cursors. However, the spec doesn't provide guidance on how drivers should determine cursor type when maxAwaitTimeMS is set on aggregate, specifically regarding the $changeStream stage.
Motivation
Who is the affected end user?
Anyone using
How does this affect the end user?
Users who set maxAwaitTimeMS on aggregate operations may experience server errors ("cannot set maxTimeMS on getMore command for a non-awaitData cursor") mid-iteration if the driver incorrectly sends maxTimeMS on getMore for non-tailable cursors. This could be a non-obvious drivers bug (e.g. GODRIVER-3806).
How likely is it that this problem or use case will occur?
Edge case. Most users don't set maxAwaitTimeMS on regular aggregates. However, users who copy patterns from change stream code or misunderstand the option could hit this.
If the problem does occur, what are the consequences and how severe are they?
Confusing server error mid-iteration after some documents are already processed
Is this issue urgent?
No
Is this ticket required by a downstream team?
No
Is this ticket only for tests?
No
Acceptance Criteria
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 currently no such requirements for this case.
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.
Add unified spec tests for aggregate pipelines with $changeStream to https://github.com/mongodb/specifications/blob/master/source/client-side-operations-timeout/tests/tailable-awaitData.yml
- is duplicated by
-
GODRIVER-3806 maxTimeMS incorrectly sent on getMore for non-tailable cursors when maxAwaitTime is set
-
- Needs Triage
-
- is related to
-
GODRIVER-3806 maxTimeMS incorrectly sent on getMore for non-tailable cursors when maxAwaitTime is set
-
- Needs Triage
-