SERVER-80363 introduced changes to the way the write concern for a batch write request has to be applied. This introduced a regression in the execution of a shardCollection operation, which sends a BatchedCommandRequest to the config server for committing the chunk list of the targeted namespace: since such a logic sets the majority write concern on the request object without also configuring the opCtx used for its submission, the config server ends up applying the w:1 default value.

This may lead to a situation of metadata inconsistency on the config server through the following sequence:

1. createCollectionCoordinator requests the creation of the collections chunks through BatchedCommandRequest as the 1st step of the DDL commit
2. the config server performs the batch write and returns an OK result to the coordinator as soon as writes are persisted by the primary node
3. the config server steps down before step 1 gets replicated; the list of chunks gets hence rolled back
4. createCollectionCoordinator receives the OK about step 1, and proceed to commit the rest of the metadata on the config server (subsequents requests are server by the new CSRS primary)
5. createCollectionCoordinator considers the metadata commit as complete, but at the first attempt of refreshing its cached copy of the routing table it will detect the inconsistency.