[SERVER-76953] Support unordered operations on mongos Created: 09/May/23 Updated: 29/Oct/23 Resolved: 01/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Vishnu Kaushik | Assignee: | Vishnu Kaushik |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | milestone-2 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Repl 2023-05-29, Repl 2023-06-12 | ||||||||
| Participants: | |||||||||
| Description |
|
On ordered operations, mongos will stop processing replies on the first error it sees. For unordered operations this is not the case. So mongos expects to get back a number of replies corresponding to the number of operations it sent in the case of unordered operations. However, for certain kinds of errors such as StaleConfig errors, mongod stops processing operations right away (even for unordered operations) and this violates the contract with mongos. We can solve this by "filling up" the rest of the reply vector with copies of the last error in the case of StaleConfig, etc. This is currently the model in use by batch write operations. After this ticket is complete, the unit tests here will need to be altered - they are testing that after a single StaleConfig error, even in unordered operations there are no more reply items. However that will no longer be the case. |
| Comments |
| Comment by Githook User [ 01/Jun/23 ] |
|
Author: {'name': 'kauboy26', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}Message: |
| Comment by Vishnu Kaushik [ 26/May/23 ] |
|
What I did was instead of actually duplicating staleness errors, I chose to have mongos interpret the last error as having appeared more than once in the unordered case. Outside of the mongos-mongod interaction I don't think any of our other systems care about whether the result array's size matches the original array's size, so this should be OK. |
| Comment by Vishnu Kaushik [ 17/May/23 ] |
|
There's also an open question of targeting errors should be handled in the (un)ordered case. Feel free to push this to |