This came up with the TenantMigrationsDonorService, but any primary service could cause this.

One such example is when we use the stopReplicationAndEnforeNewPrimaryToCatchUp function to test catchup in several places. For these tests, we'd want some node A to be elected but still be behind the current primary. Any internal write that generates an oplog entry can cause A to lose the election if other nodes replicate the write and A does not. These tests run with chaining enabled, which makes such a scenario more likely.

This could be a problem for testing replica sets in general since it could cause a node's lastApplied opTime to be different than what we'd expect. One such impact is that it could result in a desired node failing to get elected, but there are many other possible ways this could interfere with testing replica sets.