Summary

When the pauseMigrationsDuringMultiUpdates cluster parameter is enabled, multi-update and multi-delete operations are routed through the MultiUpdateCoordinator via a single internal _shardsvrCoordinateMultiUpdate command sent to the database primary shard. This path bypasses the normal per-shard dispatch loop in BatchWriteExec::executeBatch, where stats->noteTargetedShard() is called as each shard is targeted (batch_write_exec.cpp#L180).

Instead, a single coordinateMultiUpdate() call (batch_write_exec.cpp#L674) is dispatched and noteTargetedShard() is never called for any of the shards in childBatches. As a result, BatchWriteExecStats::getTargetedShards() returns an empty set on mongos, and the subsequent assignment in cluster_write_cmd.cpp (#L784):

int nShards = stats.getTargetedShards().size();  // always 0
CurOp::get(opCtx)->debug().nShards = nShards;

always stores 0, regardless of how many shards the update actually touched.

This causes incorrect nShards: 0 to appear in:

The slow query log — OpDebug::report() (op_debug.cpp#L324)
The system profiler and db.currentOp() — OpDebug::append() (op_debug.cpp#L618)
The $currentOp aggregation stage — OpDebug::appendStaged() (op_debug.cpp#L953)