-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
Sharding EMEA 2023-10-30, CAR Team 2023-11-13, CAR Team 2023-11-27, CAR Team 2023-12-11, CAR Team 2023-12-25, CAR Team 2024-01-08, CAR Team 2024-01-22, CAR Team 2024-02-05, CAR Team 2024-02-19, CAR Team 2024-03-04, CAR Team 2024-03-18, CAR Team 2024-04-01, CAR Team 2024-04-15, CAR Team 2024-04-29, CAR Team 2024-05-13
-
1
-
🟥 DDL
-
None
-
None
-
None
-
None
-
None
-
None
If a sharded DDL operation fails, the errmsg may look something like the following (collMod in this example):
{
"ok" : 0,
"errmsg" : "Failed command { _shardsvrCollModParticipant: \"coll\", collModRequest: { index: { keyPattern: { _id: 1.0, hidden: true } } }, writeConcern: { w: \"majority\", wtimeout: 60000 }, lsid: { id: UUID(\"1fd1db26-b084-4117-a2e6-bcc14ccf8a23\"), uid: BinData(0, BB89D3175FB0981C86826C27759082A37160471F60504B4612415186C630AB70) }, txnNumber: 6, $audit: { $impersonatedUsers: [ { user: \"__system\", db: \"local\" } ], $impersonatedRoles: [] } } for database 'sharded_coll_mod_error' on shard 'sharded_coll_mod_error-rs0' :: caused by :: no expireAfterSeconds, hidden, unique, or prepareUnique field",
"code" : 72,
"codeName" : "InvalidOptions",
"$clusterTime" : {
"clusterTime" : Timestamp(1646664932, 17),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1646664932, 13)
}
This errmsg may be confusing to a user because
- It is very long and hard to parse the actual error ("no expireAfterSeconds, hidden, unique, or prepareUnique field")
- It references an internal command that the user does not know about (_shardsvrCollModParticipant in this case)