[SERVER-60624] txn_commit_optimizations_for_read_only_shards.js pauses replication on coordinator and can leave transaction stuck in prepare Created: 12/Oct/21 Updated: 29/Oct/23 Resolved: 29/Dec/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 5.3.0, 5.0.6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Luis Osta (Inactive) | Assignee: | Matt Boros |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, sharding-nyc-subteam1, sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v5.2, v5.0
|
||||||||||||||||
| Sprint: | Sharding 2021-12-13, Sharding 2021-12-27 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 23 | ||||||||||||||||
| Story Points: | 2 | ||||||||||||||||
| Description |
|
Context This means that the commitTransaction command will return early as soon as the _decisionPromise gets emplaced (either successfully or due to an error). This means that the next test case will be able to start before the TransactionCoordinator is finished with the existing transaction. Which is part of the coverage for this test. The problem This results in the following being possible:
Since the issue arises form the test stopping replication with the coordinateCommitReturnImmediatelyAfterPersistingDecision flag enabled, this is a test-only problem Proposed Solution |
| Comments |
| Comment by Githook User [ 30/Dec/21 ] |
|
Author: {'name': 'Matt Boros', 'email': 'matt.boros@mongodb.com'}Message: (cherry picked from commit 6e8beaab454ba83cf6123625de45bc0b22fb1079) |
| Comment by Githook User [ 30/Dec/21 ] |
|
Author: {'name': 'Matt Boros', 'email': 'matt.boros@mongodb.com'}Message: (cherry picked from commit 6e8beaab454ba83cf6123625de45bc0b22fb1079) |
| Comment by Githook User [ 17/Dec/21 ] |
|
Author: {'name': 'Matt Boros', 'email': 'matt.boros@mongodb.com'}Message: |
| Comment by Max Hirschhorn [ 22/Nov/21 ] |
Another thought here would be to give each test case a unique logical session ID to run with. This way each test won't need to wait for the cross-shard transaction from the previous test case to finish executing. |
| Comment by Luis Osta (Inactive) [ 12/Oct/21 ] |
|
The server parameter in question was introduced as part of |