Skip to content
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

Merged
merged 2 commits into from Oct 20, 2021
Merged

Conversation

durran
Copy link
Member

@durran durran commented Oct 19, 2021

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 and opTime are optional fields in results that can be either a Timestamp, or an object with a ts and t property of Timestamp and Long respectively. In some cases they are both Longs. Our comparison logic on these values could get into a hot mess when trying to compare values of different types. This changes the lastOp value in the bulk write result to always be an object with the ts and t fields and never sets it as a Timestamp 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

  • Ran npm run check:lint script
  • Self-review completed using the steps outlined here
  • PR title follows the correct format: <type>(NODE-xxxx)<!>: <description>
  • Changes are covered by tests

@nbbeeken nbbeeken self-requested a review October 19, 2021 21:11
@nbbeeken nbbeeken added the Primary Review In Review with primary reviewer, not yet ready for team's eyes label Oct 19, 2021
@durran durran changed the title fix: do proper opTime merging in bulk ressults fix(HELP-28460): do proper opTime merging in bulk ressults Oct 19, 2021
Copy link
Contributor

@nbbeeken nbbeeken left a 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!

test/unit/bulk_write.test.js Outdated Show resolved Hide resolved
lib/bulk/common.js Outdated Show resolved Hide resolved
@nbbeeken nbbeeken changed the title fix(HELP-28460): do proper opTime merging in bulk ressults fix(NODE-3515): do proper opTime merging in bulk results Oct 20, 2021
@nbbeeken nbbeeken requested a review from dariakp October 20, 2021 14:38
@nbbeeken nbbeeken added Team Review Needs review from team and removed Primary Review In Review with primary reviewer, not yet ready for team's eyes labels Oct 20, 2021
lib/bulk/common.js Outdated Show resolved Hide resolved
test/unit/bulk_write.test.js Outdated Show resolved Hide resolved
test/unit/bulk_write.test.js Outdated Show resolved Hide resolved
// 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') {
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

@nbbeeken nbbeeken merged commit 428e6d3 into 3.7 Oct 20, 2021
@nbbeeken nbbeeken deleted the HELP-28460 branch October 20, 2021 17:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team Review Needs review from team
Projects
None yet
3 participants