GODRIVER-3473 Short-cicruit cursor.next() on invalid timeouts #2135
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GODRIVER-3473
Summary
Short-circuit calls to
cursor.Next()
where maxAwaitTimeMS >= operation timeout, which would result in socket timeouts.Background & Motivation
The specifications assume that drivers iteratively apply the timeout provided at the constructor level (e.g.,
(*collection).Find
) for tailable awaitData cursors:The Go Driver might decide to support the above behavior with DRIVERS-2722. The principal concern is that it would be unexpected for users to apply an operation-level timeout via contexts to a constructor and then have that timeout later be applied while working with a resulting cursor. Instead, it is more idiomatic to apply the timeout to the context passed to
Next
orTryNext
.