[SERVER-46811] multi=true updates can modify the shard key of orphan documents and cause them to become owned Created: 11/Mar/20  Updated: 29/Oct/23  Resolved: 14/Jul/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 4.2.0
Fix Version/s: 4.4.1, 4.7.0, 4.2.15

Type: Bug Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Haley Connelly
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-39780 Throw WouldChangeOwningShard exceptio... Closed
is related to SERVER-47105 Make update stage use OwnershipFilter... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4, v4.2
Sprint: Sharding 2020-07-13, Sharding 2020-06-15, Sharding 2020-06-29
Participants:

 Description   

The check for whether the shard key is being modified in a multi=true update happens after the check for whether the shard owns the document being updated has said it's fine to proceed with the update. We should instead disallow any attempts to change the shard key in multi=true updates.

// If the shard key fields remain unchanged by this update or if this document is an orphan and
// so does not belong to this shard, we can skip the rest of the checks.
if ((newShardKey.woCompare(oldShardKey) == 0) || !metadata->keyBelongsToMe(oldShardKey)) {
    return false;
}
 
...
 
// We do not allow updates to the shard key when 'multi' is true.
uassert(ErrorCodes::InvalidOptions,
        "Multi-update operations are not allowed when updating the shard key field.",
        !_params.request->isMulti());



 Comments   
Comment by Githook User [ 04/Jun/21 ]

Author:

{'name': 'Haley Connelly', 'email': 'haley.connelly@mongodb.com', 'username': 'haleyConnelly'}

Message: SERVER-46811 multi=true updates can modify the shard key of orphan documents and cause them to become owned

(cherry picked from commit 17e468583ec1a7e9755b34b50eaa7cf017a1c96e)
Branch: v4.2
https://github.com/mongodb/mongo/commit/b9cd445b93ec8fb8c960afef41cc31f2ac47eba7

Comment by Githook User [ 12/Aug/20 ]

Author:

{'name': 'Haley Connelly', 'email': 'haley.connelly@mongodb.com', 'username': 'haleyConnelly'}

Message: SERVER-46811 multi=true updates can modify the shard key of orphan documents and cause them to become owned

(cherry picked from commit 17e468583ec1a7e9755b34b50eaa7cf017a1c96e)
Branch: v4.4
https://github.com/mongodb/mongo/commit/3a20a63dc5e96948131dc0393c07a644f49e8109

Comment by Githook User [ 14/Jul/20 ]

Author:

{'name': 'Haley Connelly', 'email': 'haley.connelly@mongodb.com', 'username': 'haleyConnelly'}

Message: SERVER-46811 multi=true updates can modify the shard key of orphan documents and cause them to become owned
Branch: master
https://github.com/mongodb/mongo/commit/17e468583ec1a7e9755b34b50eaa7cf017a1c96e

Comment by Haley Connelly [ 29/Jun/20 ]

Just as an update: The behavior in master has changed since Max posted the repro.
It now fails here

[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.247+0000 uncaught exception: Error: write failed with error: {
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.247+0000 	"nMatched" : 0,
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.247+0000 	"nUpserted" : 0,
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.247+0000 	"nModified" : 0,
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.247+0000 	"writeError" : {
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.247+0000 		"code" : 31025,
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.248+0000 		"errmsg" : "Shard key update is not allowed without specifying the full shard key in the query"
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.248+0000 	}
[js_test:repro_update_orphan_shard_key] 2020-06-29T19:15:37.248+0000 } :

It fails with this right before it has the change to assert "Multi-update operations are not allowed when updating the shard key field".

Generated at Thu Feb 08 05:12:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.