[SERVER-50972] Make tenant migration donor startup recovery more likely to cover all the 4 possible states Created: 16/Sep/20  Updated: 29/Oct/23  Resolved: 23/Sep/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.8.0

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Jason Zhang
Resolution: Fixed Votes: 0
Labels: pm-1791_milestone-D
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-50616 TenantMigrationDonor should retry its... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-09-21, Sharding 2020-10-05
Participants:

 Description   

The existing non-deterministic test theoretically should cover all the possible states, but it's tending to mostly cover the node shutting down after the migration has already committed.

This ticket is to either:

1) Make the test randomly set one of three failpoints before starting the migration thread:

  • A failpoint to make the migration hang in the dataSync state. This failpoint doesn't exist yet and could be added here.
  • A failpoint to make the migration hang in the blocking state (already exists)
  • A failpoint to make the migration abort (already exists)

or

2) Split the test into 4 cases, one for each failpoint (to cover kDataSync, kBlocking, and kAborted) plus one without any failpoints (to cover kCommitted).



 Comments   
Comment by Githook User [ 23/Sep/20 ]

Author:

{'name': 'Jason Zhang', 'email': 'jason.zhang@mongodb.com', 'username': 'jz1242'}

Message: SERVER-50972 Make tenant migration donor startup recovery more likely to cover all the 4 possible states
Branch: master
https://github.com/mongodb/mongo/commit/6e8989d533886a774700689b46b90542b569c5eb

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