[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?

see https://github.com/10gen/mongo/blob/b02796c77befd906e90ed7c1cd764c888d90524c/src/mongo/db/repl/tenant_migration_recipient_op_observer.cpp#L101-L109

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.

Generated at Thu Feb 08 05:56:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.