When the primary shard returns ok:1 to the router upon a drop collection command, due to SERVER-97754 it is guaranteed that the drop has been majority acknowledged.

However - since the DDL coordinator writes using a separate operation context - when the shard command returns it waits for the last op time to get majority committed (SERVER-102024). The last op time may be ahead of the drop op time.

It follows that - when the additional wait fails - a write concern error gets attached to the reply even though the drop succeeded and was majority committed. When that happens, the router will fail to parse the shard reply because the DropReply does not include a writeConcernError field.

SERVER-103506 should solve the problem for all command replies. But we should provide a temporary solution as long as the generic fix is not in.