-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
Sharding 2021-02-08
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
- abortTenantMigrationAfterBlockingStarts and pauseTenantMigrationAfterBlockingStarts currently live in the .then after the donor gets a response for recipientSyncData with returnAfterReachingDonorTs. So technically, at that point the migration is already at the end of the blocking state (the donor starts blocking writes and reads after the “blocking” write is majority-committed). It’s misleading that the names have “AfterBlockingStarts” in them especially in this this tenant_migration_donor_state_machine.js test case that sets abortTenantMigrationAfterBlockingStarts and expects the donor to have sent two recipientSyncData commands since the blocking state technically starts right after the first recipientSyncData.
- pauseTenantMigrationAfterDataSync lives in the .then after the donor gets a response for the initial recipientSyncData. So the failpoint should be renamed to make this clear.