[SERVER-62885] Clarify Tenant Migration Recipient Op Observer access blocker removal condition(s) Created: 21/Jan/22 Updated: 04/Oct/23 Resolved: 04/Oct/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Christopher Caplinger | Assignee: | [DO NOT USE] Backlog - Server Serverless (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | pos-improvements | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Serverless
|
| Operating System: | ALL |
| Participants: |
| Description |
|
Should the Tenant Migration Recipient remove its access blocker on forget if the access blocker is in rejectBefore, not just reject? do we need this mtab state check at all? |
| Comments |
| Comment by Didier Nadeau [ 04/Oct/23 ] |
|
Closing as we're planning to decommission TM . |
| Comment by Suganthi Mani [ 18/Aug/23 ] |
|
didier.nadeau@mongodb.com It's a issue only with legacy tenant migration protocol. In shard merge, the recipient know whether the migration is committed or aborted. So, it not a problem with shard merge. Just to add more context, not fixing this issue, will cause migration retry to fail unnecessarily due to presence of conflicting access blocker . It doesn't affect tenant migration correctness (i.e, doesn't cause data corruption). so, I am ok of closing the ticket as "Won't do". |
| Comment by Didier Nadeau [ 18/Aug/23 ] |
|
suganthi.mani@mongodb.com could you take a look and check if this issue also applies to ShardMergeRecipientService ? If it does not I'd close it as it only applies to Tenant Migration ! |
| Comment by Christopher Caplinger [ 25/Jan/22 ] |
|
chatted with esha.maharishi more about this, came to the conclusion that we (likely) don't need this block of code at all, since it appears to be an optimization that ends up making things a bit more confusing. In the event of a retry, we end up here if the previous access blocker is still hanging around, we delete the existing state doc (that is, if the migration has in fact been aborted/marked as garbage... see deleteStateDocIfMarkedAsGarbageCollectable), which will trigger TenantMigrationRecipientOpObserver::onDelete, which will end up cleaning up the blocker. |