[SERVER-59484] Catch FailedToSatisfyReadPreference in DDL fsm workloads Created: 20/Aug/21  Updated: 14/Oct/21  Resolved: 06/Oct/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 5.1.0, 5.0.2
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Jason Zhang Assignee: Pierlauro Sciarelli
Resolution: Won't Do Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
related to SERVER-59409 Race between reconfig replication and... Closed
is related to SERVER-60706 Retry FailedToSatisfyReadPreference e... Backlog
Operating System: ALL
Backport Requested:
v5.0
Sprint: Sharding EMEA 2021-09-06
Participants:
Linked BF Score: 144

 Description   

If the RSM on any node times out while trying to discover a new primary host, we could throw FailedToSatisfyReadPreference. We should account for that error in this test.



 Comments   
Comment by Pierlauro Sciarelli [ 06/Oct/21 ]

Thanks for pointing that out Lamont! Closing in favor of SERVER-60495 that will make DDL coordinators retry such error, so that tests will not have to catch it.

Comment by Lamont Nelson [ 06/Oct/21 ]

This ticket is separate from SERVER-59409. They both share the symptom of FailedToSatisfyReadPreference, but the underlying reasons are different.

See BF-21948 for details.

Comment by Pierlauro Sciarelli [ 07/Sep/21 ]

Closing because the real problem this ticket is trying to solve will be tackled in SERVER-59409

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