-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 4.9.0-alpha4
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
Sharding 2021-04-05, Sharding EMEA 2021-05-03, Sharding EMEA 2021-05-17
After SERVER-55033 there is still one situation where OpObserverShardingImpl::shardObserveDeleteOp will not throw upon attempting to delete a document in a txn on a chunk that has moved since the atClusterTime. This situation happens when the collection has a nested shard key.
For instance:
OpObserverImpl::getDocumentKey() calls dotted_path_support::extractElementsBasedOnTemplate() and would return an object {"x.y": 10}.
OpObserverShardingImpl::shardObserveDeleteOp() calls ShardKeyPattern::extractShardKeyFromDocThrows() which would fail to find the shard key because there is no field call "x" in the object {"x.y": 10}. There is only a field called "x.y".
Possible solutions could be:
a) Make shardObserveDeleteOp() receive the full document, so it can call extractShardKeyFromDoc() itself. This would likely cause a performance regression since we would need to save a copy of the full document in aboutToDelete().
b) Make shardObserveDeleteOp() receive the shard key (without the _id, unless _id was part of the shard key pattern) so that it can skip calling extractShardKeyFromDoc*() itself. shardObserveDeleteOp() also needs to receive the _id separately so it can be given to MigrationChunkClonerSourceLegacy::onDeleteOp()
c) Make OpObserverImpl::getDocumentKey set the shard key BSONObj as nested object (if the shard key was nested), instead of setting it as dot-notation.
- related to
-
SERVER-55033 OpObserverImpl should pass the shard key when calling shardObserveDeleteOp
- Closed
-
SERVER-56127 Retryable update may execute more than once if chunk is migrated and shard key pattern uses nested fields
- Closed