[DRIVERS-2139] Test retryable writes against real shutdown scenarios Created: 12/Oct/18 Updated: 21/Dec/23 |
|
| Status: | Backlog |
| Project: | Drivers |
| Component/s: | Retryability |
| Fix Version/s: | None |
| Type: | Spec Change | Priority: | Major - P3 |
| Reporter: | Shane Harvey | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Driver Changes: | Needed | ||||||||||||||||
| Description |
|
In The specific scenario where PyMongo's bug would be hit is when:
The fix implemented in PyMongo 3.7.2 is to always increment the txnNumber before server/socket selection (similar to how start_transaction works). Note that it would be much less likely for this to occur if PYTHON-1435 was implemented because server selection would wait for the new primary on the initial attempt. |
| Comments |
| Comment by Esha Bhargava [ 10/Feb/20 ] | |||
|
This work will be done post 4.4 | |||
| Comment by Prashant Mital (Inactive) [ 04/Nov/19 ] | |||
|
jeff.yemin Indeed it is. Thanks for pointing it out! | |||
| Comment by Jeffrey Yemin [ 01/Nov/19 ] | |||
|
CC prashant.mital maybe relevant for planned maintenance testing scenarios. | |||
| Comment by Bernie Hackett [ 12/Oct/18 ] | |||
|
That is precisely the bug, and what happened in the reproduction. Even worse, the initial write was an insert, the retry write was an update, and the server converted the reply to the retry (which was the reply from the successful insert) into an upsert... | |||
| Comment by A. Jesse Jiryu Davis [ 12/Oct/18 ] | |||
|
So PyMongo could use a completely unrelated txnNumber for an operation?
| |||
| Comment by Shane Harvey [ 12/Oct/18 ] | |||
|
We do have a single prose test that tests with a real replica set stepdown ( |