The recipient in a tenant migration is guaranteed to persist an oplog entry with a timestamp >= the migration's block timestamp, but cluster time can advance on the donor after the block timestamp has been selected (from writes to other tenant's data or internal collections). This means the operation time a client receives when reading from the donor may be greater than the block timestamp, so if it performs an afterClusterTime read on the recipient after the migration finishes, that timestamp may not exist in the recipient's oplog, leading to a stall waiting for write concern until the next write on the recipient - from any tenant, background activity, or the periodic noop writer (the next write is guaranteed to satisfy the afterClusterTime because cluster times from the donor are gossiped to the recipient). A similar problem exists in sharded clusters and is handled by writing a noop oplog entry, but this logic is disabled for standalone replica sets.