The MongoS implementation of write commands (using dbclient_multi_command) obtains connections from the shardConnectionPool while the MongoD side of the implementation checks the connection state for the presence of sharding information.

The assumption that MongoS makes is that all connections on the shardConnectionPool have at some point previously sent setShardVersion to mark the connection as sharded.

Even though the write commands send the shard version information along with the command, the MongoD side will silently drop and not use this information, unless it comes over a sharded connection, because of this check in batch_executor.cpp:

    ShardedConnectionInfo* info = ShardedConnectionInfo::get(_txn->getClient(), false);
    if (info) {
        auto rootRequest = updateItem.getRequest();
        if (!updateItem.getUpdate()->getMulti() && rootRequest->isMetadataSet() &&
            rootRequest->getMetadata()->isShardVersionSet()) {
            info->setVersion(rootRequest->getTargetingNS(),
                             rootRequest->getMetadata()->getShardVersion());
        } else {
            info->setVersion(rootRequest->getTargetingNS(), ChunkVersion::IGNORED());
        }
    }

Connections in the shardConnectionPool are not guaranteed to always have called setShardVersion (and thus established ShardedConnectionInfo) on the MongoD side. Therefore, if a MongoS is cleanly started and it is only receiving write commands, the shard information will keep getting ignored and it may never refresh its metadata, thus causing data corruption.