[SERVER-41146] commitTransaction on mongos can leave the transaction open on some participants if one participant returns an error Created: 14/May/19 Updated: 27/Oct/23 Resolved: 16/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Operating System: | ALL |
| Participants: |
| Description |
|
This is because the ARS is not guaranteed to send a request to each remote at least once: the ARS can be destroyed before scheduling all the requests, which will cause the requests that had yet to be scheduled to return this error. The fix could be to make commitTransaction use gatherResponses, which fully exhausts the ARS before returning. However, for the single-write-shard commit path, we should take care to send abortTransaction to the single write shard if one of the read-only shards returned an error to commitTransaction. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 16/May/19 ] |
|
Closing as Works as Designed - I thought the implicit abort was only executed in this catch block, and since commitTransaction returns a participant's error response instead of throwing if a participant returns an error, that the implicit abort was not being executed after commitTransaction. But actually the implicit abort is also called here where it checks the response object for 'ok:0'. |