[SERVER-51471] Make `sharding_legacy_api_test` resilient to inaccurate timers Created: 09/Oct/20  Updated: 01/May/23

Status: Backlog
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Amirsaman Memaripour Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-34857 `sharding_legacy_api_test` is flaky d... Closed
Assigned Teams:
Service Arch
Operating System: ALL
Backport Requested:
v4.4, v4.2, v4.0, v3.6
Sprint: Service Arch 2023-05-01
Participants:
Linked BF Score: 33

 Description   

The test heavily relies on timers (e.g., curTimeMicros64()) to test the order of events. This could potentially cause failures if the timer does not advance between two events (e.g., see here and here).

This ticket should improve the usage of timers in this test to make sure a non-increasing timer would not cause test-failures. A potential solution is to introduce artificial delays between the points of interest, as previously done by SERVER-34857.

This test is only available on 3.6, 4.0, 4.2, and 4.4.



 Comments   
Comment by Blake Oler [ 17/Nov/21 ]

Closing, as test no longer exists in the current branch.

Comment by Kaloian Manassiev [ 12/Feb/21 ]

Yes, this test was related to map/reduce and the legacy sharding commands, so it is no longer present in master.

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