With the server parameter ClearCollectionShardingRuntimesOnRecovery set to "false" (defaults to "true"), CollectionShardingRuntime::clearCollectionMetadata is never called on rollback, which in turn means that ongoing disk acquisitions are not canceled. Consequently, any "c" oplog entry emitted after the synchronizer makes the snapshot read is registered for later application, and if they get rolled back, then there is nothing preventing the synchronizer from applying the now stale oplog entry at any arbitrary point in time after the rollback has completed.

There is no empirical evidence of this bug nor are the practical consequences known, thus is is an investigation ticket.