[SERVER-66388] Disallow using transaction API in operations with shard versions Created: 11/May/22 Updated: 29/Oct/23 Resolved: 11/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc8, 6.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Backport Requested: |
v6.0
|
||||
| Sprint: | Sharding NYC 2022-05-16 | ||||
| Participants: | |||||
| Description |
|
The internal transactions API will inherit options from its caller's opCtx, like read and write concern, but notably it does not inherit shard or database versions. If an operation on a shardsvr with shard versions used the API, the API's spawned commands would not include those versions and thus wouldn't obey sharding protocols, e.g. could read/write to orphan documents or during a migration critical section. To be correct, the API should probably forward any shard versions in commands against the same namespaces, but it's unclear what to do if other namespaces are targeted by the transaction. No current uses of the API run in this case, so to prevent accidental misuse we should add an assertion to disallow using the API when its caller has a shard/db version and we can relax it if future if necessary when requirements are more clear. This doesn't need to apply if the transaction is acting as a router because the router commands will attach appropriate shard/db versions. |
| Comments |
| Comment by Githook User [ 28/May/22 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit 51bff7a1d0145afebb57a04e82bd962985801f06) |
| Comment by Githook User [ 11/May/22 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |
| Comment by Jack Mulrow [ 11/May/22 ] |
|
The only case that fails the proposed assertion is explain for FLE update and delete, which was unintentional and will be fixed by |