-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(NODE-3515): do proper opTime merging in bulk results #3011
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at the 4.x port at the same time and that LGTM with the same changes I'm asking about here. Thanks for this!
lib/bulk/common.js
Outdated
// If the opTime is a Timestamp, convert it to a consistent format to be | ||
// able to compare easily. Converting to the object from a timestamp is | ||
// much more straightforward than the other direction. | ||
if (opTime._bsontype === 'Timestamp') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we have an else
with an assertion about the shape to make sure that if it's unexpected we fail in a predictable manner?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we need an else in this case as we basically just want to convert if that object is a timestamp and continue on. Any other value it would be at this point (only an object) is valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose that's fine, I was thinking about a case where the server is sending an object that doesn't have the expected shape (for example, missing or wrong type on one or both of t, ts), but that's probably low risk enough
Description
Fixes the merging of results in a bulk write inside a transaction to properly compare and set the
lastOp
value in the result.What is changing?
Per various specifications,
lastOp
andopTime
are optional fields in results that can be either aTimestamp
, or an object with ats
andt
property ofTimestamp
andLong
respectively. In some cases they are bothLongs
. Our comparison logic on these values could get into a hot mess when trying to compare values of different types. This changes thelastOp
value in the bulk write result to always be an object with thets
andt
fields and never sets it as aTimestamp
value anymore.Is there new documentation needed for these changes?
No
What is the motivation for this change?
This was reported as a bug in HELP-28460 and related to NODE-3515, although the user provided patch did not solve all potential cases.
Double check the following
npm run check:lint
script<type>(NODE-xxxx)<!>: <description>