For an update that has no shard-key specified in the q field but does have the _id field specified, we take a special optimized path, since we know the update should only apply in exactly one shard. We can avoid the expensive two-phase protocol normally used by updateOne when no shard key is specified.

For this path, if we retry such an update (with the same lsid and txnid) then we will double-count it in query stats. E.g., it will show two executions, even if in the second retry we didn't do anything because the update was already applied.

This was caught by a test case I wrote for SERVER-120403.