-
Type:
Task
-
Resolution: Fixed
-
Priority:
Minor - P4
-
None
-
Component/s: Client Side Encryption, Load Balancer, Unified Test Runner
-
None
-
Not Needed
-
Summary
I noticed that a handful of spec tests (both legacy and unified) only expect an int64 BSON type for the cursor ID in an observed getMore command. The vast majority of specs use a flexible assertion that allows int32 or int64 to accommodate drivers that encode BSON integers in the smallest possible type depending on its value.
Instead of:
getMore: { $$type: long }
Tests should use:
getMore: { $$type: [ int, long ] }
Motivation
Who is the affected end user?
Drivers that may conditionally encode integers as int32 or int64, range permitting.
How likely is it that this problem or use case will occur?
Rare. Cursor IDs are usually greater than INT32_MAX.
If the problem does occur, what are the consequences and how severe are they?
Possible test failure.
Is this issue urgent?
No.
Is this ticket required by a downstream team?
No.
Is this ticket only for tests?
Yes.
- split to
-
-
- Closed
-