[DRIVERS-2102] Do not prohibit retryability for all commands issued from bulkWrite() due to requests Created: 18/Dec/17  Updated: 29/Jun/22  Resolved: 29/Jun/22

Status: Closed
Project: Drivers
Component/s: Retryability
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Jeremy Mikola Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Driver Changes: Not Needed

 Description   

While testing CDRIVER and PHPC with APM to inspect command documents, I noticed something surprising. If a bulk operation contains a series of single-document operations (e.g. deleteOne, updateOne) followed by a final multi-document operation (e.g. updateMany), only the final command containing the unsupported operation excludes a transaction ID. Based on the language in Unsupported Write Operations, I might expect that one unsupported operation to cause all commands to exclude a transaction ID:

In the context of the CRUD specification, this includes the updateMany() and deleteMany() methods as well as bulkWrite() where the requests parameter includes an UpdateMany or DeleteMany operation. Drivers MUST NOT add a transaction ID to any single- or multi-statement write commands that include one or more multi-document write operations. Drivers MUST NOT retry these commands if they fail to return a response.

This reason for this behavior is that libmongoc checks for a "multi" operation while building individual write command documents (similar to its checks for "collation" option usage), rather than in its bulk write API where delete, insert, and update operations are added.

I've forgotten the thought process that went into the above citation from the retryable writes spec, but I don't see anything technically wrong with what libmongoc is doing. Therefore, I propose rewording the spec to relax the tainting of an entire bulkWrite() based on its requests parameter and instead allow drivers the flexibility to taint individual write commands within a bulkWrite(). This would result in emphasizing the sentence that followed the bolded segment above:

Drivers MUST NOT add a transaction ID to any single- or multi-statement write commands that include one or more multi-document write operations.

I should note that the spec's JSON tests didn't catch this, as they are focused on testing retryable behavior in the face of network errors (i.e. fail point triggers). I ultimately caught this while implementing the Test Plan discussed in the spec document, which says:

If possible, drivers should test that transaction IDs are never included in commands for unsupported write operations:

  • Unsupported multi-statement write operations
    • bulkWrite() that includes UpdateMany or DeleteMany


 Comments   
Comment by Jeremy Mikola [ 29/Jun/22 ]

I concur. SPEC-1065 addresses the ask in this issue.

Comment by Kaitlin Mahar [ 29/Jun/22 ]

jmikola@mongodb.com I've just been going through the backlog looking at bulk related tickets and found this one. The proposed change here seems like it was made a long time ago via SPEC-1065. Can we close this?

Comment by Bernie Hackett [ 08/Jan/18 ]

Therefore, I propose rewording the spec to relax the tainting of an entire bulkWrite() based on its requests parameter and instead allow drivers the flexibility to taint individual write commands within a bulkWrite().

I agree. Make it so.

Generated at Thu Feb 08 08:24:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.