[SERVER-57661] Recipient primary should wait on a different failpoint in tenant_migration_recipient_initial_sync_cloning.js Created: 11/Jun/21  Updated: 29/Oct/23  Resolved: 21/Jun/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.0.0-rc4, 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Vishnu Kaushik Assignee: Vishnu Kaushik
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Sprint: Repl 2021-06-28
Participants:
Linked BF Score: 53

 Description   

It is possible for an update to the stateDoc with rejectReadsBeforeTimestamp information to occur while the recipient primary is waiting on the failpoint right after data consistency. This should be changed so that the recipient primary cannot advance and lead to the failure of the following replSetStepUp command.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 22/Jun/21 ]

Author:

{'name': 'Vishnu Kaushik', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}

Message: SERVER-57661 Recipient primary should wait on a different failpoint in tenant_migration_recipient_initial_sync_cloning.js
Branch: v5.0
https://github.com/mongodb/mongo/commit/99c2e2b092412ea1a0b97a649b19c3043d0420f2

Comment by Githook User [ 17/Jun/21 ]

Author:

{'name': 'Vishnu Kaushik', 'email': 'vishnu.kaushik@mongodb.com', 'username': 'kauboy26'}

Message: SERVER-57661 Recipient primary should wait on a different failpoint in tenant_migration_recipient_initial_sync_cloning.js
Branch: master
https://github.com/mongodb/mongo/commit/381f5e18a80b2aba0eacbd8e342e00ad7da2d099

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