[SERVER-50914] cursor_valid_after_shard_stepdown.js can fail because of an unintended metadata refresh Created: 14/Sep/20  Updated: 29/Oct/23  Resolved: 22/Oct/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.7.0, 4.4.2, 4.2.12

Type: Bug Priority: Major - P3
Reporter: Marcos José Grillo Ramirez Assignee: Jordi Serra Torrens
Resolution: Fixed Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-48096 PeriodicShardedIndexConsistencyChecke... Closed
related to SERVER-50900 Disable PeriodicShardedIndexConsisten... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

1. The primary node steps down as part of the test
2. A step down happens on the config server due to the test suite parameter
3. The new node is elected primary for the first time, so it runs the periodic index check aggregation
4. The sharding metadata is refreshed on the shard
5. The test assertion fails because it is expecting a stale sharding metadata

Sprint: Sharding 2020-11-02
Participants:
Linked BF Score: 25

 Description   

When running the sharding_csrs_continuous_config_stepdown suite, the cursor_valid_after_shard_stepdown.js test expects to have stale sharding metadata, but the following scenario might happen:

1. The primary node steps down as part of the test
2. A step down happens on the config server
3. The new node is elected primary for the first time, so it runs the periodic index check aggregation
4. The sharding metadata is refreshed on the shard
5. The test assertion fails because it is expecting a stale sharding metadata

One way to solve this is to disable the periodic index check like this test



 Comments   
Comment by Jordi Serra Torrens [ 22/Oct/20 ]

It was already fixed on SERVER-50900

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