For a top-level batched WriteUnitOfWork (not a multi-document transaction, with oplog grouping enabled), getGroupType() chooses the grouping mode solely on txnNumber presence: kGroupForRetryableAtomicWrite if present, kGroupForTransaction otherwise.

But a retryable write can perform internal, statement-less writes (fromMigrate, no stmtId) in their own WriteUnitOfWork(s), separate from the WUOW that carries its actual retryable statement, and all of these run under the same opCtx and the same txnNumber. Keying the grouping decision off txnNumber presence alone treats every batched WUOW under that session as the retryable statement, including the internal writes that carry none: a present txnNumber means the session is retryable, not that this WUOW is the retryable statement.

This happens in sharded convertToCapped, which runs its shard step (_shardsvrConvertToCappedParticipant) as a retryable write for idempotency under coordinator retry. The conversion clones documents via cloneCollectionAsCapped using internal fromMigrate inserts in per-document WUOWs (all statement-less), and issues one explicit dummy write at the end to carry the retryable statement. When a capped delete joins a clone insert in the same WUOW, that batch has multiple ops and zero statement-bearing ops, so it is misgrouped as a retryable atomic write.