[SERVER-31142] Implement failpoint for testing retryable, multi-statement writes Created: 18/Sep/17 Updated: 27/Oct/23 Resolved: 18/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jeremy Mikola | Assignee: | Jack Mulrow |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Sprint: | Sharding 2017-10-02, Sharding 2017-10-23 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
In this test, the driver's bulkWrite() CRUD method is called with an ordered sequence of delete, insert, and update operations. This will be executed as three write commands. The test suite needs the ability to configure a fail point so that only the first attempt of each of these three write commands fails, in order to verify that the driver successfully retries individual write commands once to allow the entire bulkWrite() to succeed. Per kaloian.manassiev's comments:
|
| Comments |
| Comment by Jeremy Mikola [ 18/Oct/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Closing per my comment in SPEC-966. Drivers can use the fail point as-is to test what we need to. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeremy Mikola [ 11/Oct/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sorry, I meant to write "tied to statements." I think my misunderstanding stemmed from overlooking "as opposed to the separate commits that happen within a command" in your original comment (quoted in the issue description). Please see my comment in SPEC-966. I believe we can use skip to delay the fail point until the last statement in a multi-statement write command. If so, I think we can make do with the current design. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 11/Oct/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Not sure what you mean by "tied to transaction IDs". It just specifies what code to throw when we try to commit one operation from a batch of writes. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeremy Mikola [ 11/Oct/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
kaloian.manassiev: I think so. shane.harvey explained to me how failBeforeCommitExceptionCode works (I didn't realize it was tied to transaction IDs). Let me make some changes to the retryable write spec tests to take advantage of that option and times and I'll follow up once we confirm we can get by with the existing fail point design. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kaloian Manassiev [ 11/Oct/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks, shane.harvey. jmikola, does what Shane is describing work for your use case and can we close this ticket? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Shane Harvey [ 10/Oct/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The onPrimaryTransactionalWrite fail point can already fail the first attempt of each consecutive write command:
I think this ticket can be closed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeremy Mikola [ 06/Oct/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
kaloian.manassiev: Note that in the variant jeff.yemin shared, we effectively need to interleave skips and failures. I'm not sure that "a combination of skip + nTimes" alone would do the trick. This is why I originally proposed an errorOnFirstAttemptOnly option in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 21/Sep/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Another variant which is required:
As this lets clients test retries during batch splitting |