[SERVER-41435] Blacklist sharding_statistics_server_status.js from config server stepdown suite Created: 31/May/19 Updated: 29/Oct/23 Resolved: 18/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.0-rc3, 4.3.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Janna Golden |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Backport Requested: |
v4.2
|
||||||||
| Sprint: | Sharding 2019-07-01 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 18 | ||||||||
| Description |
|
jstests/sharding/server_status_sharding_statistics.js sets a fail point to pause all find commands so it can verify statistics after migrations time out waiting for collection locks entering the config server commit phase. If the config server primary steps down while the fail point is set, mongos will automatically retry the migration which can trigger a metadata refresh that will hang because of the fail point, timing out the test. Running the test with config server stepdowns doesn't add meaningful coverage, so it should be blacklisted in the config stepdown suite to avoid this problem. |
| Comments |
| Comment by Githook User [ 25/Jun/19 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: (cherry picked from commit a9118cdb43cf5738b8b701caeedc45ffaff6e673) |
| Comment by Githook User [ 18/Jun/19 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |