First, we need to decide if applyOps needs to be synchronized with tenant migrations. applyOps is not supported in API Version 1, but MongoMirror uses it. So, we should check if MongoMirror and a tenant migration could ever be run simultaneously against a serverless replica set.

My guess is we should synchronize applyOps with tenant migrations, to be on the safe side.

–

When we made TenantMigrationConflict include the shared_ptr<TenantMigrationAccessBlocker>, we noticed that if TenantMigrationConflict was thrown in the op observer for applyOps, the shared_ptr got lost somewhere on the way back up to migrationConflictHandler.

Therefore, we disabled making applyOps wait for the migration to commit or abort.

This ticket is to:

• make applyOps wait for the migration to commit or abort at the point where it catches the TenantMigrationConflict error,
• confirm that TenantMigrationCommitted/TenantMigrationAborted are reported in line with how other errors are reported for applyOps. In particular, for non-atomic applyOps, it may be possible that some of the operations occurred but others didn't. Does the applyOps response need to indicate this in some way?

I think for applyOps, the oplog entries are written here or here, and TenantMigrationConflict gets caught here.