[SERVER-65177] Elapsed initial sync time in TestRemainingInitialSyncEstimatedMillisMetric unit test can be 0 ms Created: 01/Apr/22 Updated: 29/Oct/23 Resolved: 23/Aug/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.15, 6.0.4, 6.1.0-rc0, 6.2.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ali Mir | Assignee: | Ali Mir |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Backport Requested: |
v6.0, v5.0
|
||||||||
| Sprint: | Repl 2022-04-04, Repl 2022-05-02, Repl 2022-05-16, Repl 2022-05-30, Repl 2022-06-13, Repl 2022-06-27, Repl 2022-07-11, Repl 2022-08-08, Repl 2022-08-22, Repl 2022-09-05, Repl 2022-07-25 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 6 | ||||||||
| Comments |
| Comment by Githook User [ 08/Dec/22 ] |
|
Author: {'name': 'ali-mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}Message: (cherry picked from commit 9d47a813c02607ff8fb4fbc50b544ebeb494ce85) |
| Comment by Githook User [ 08/Dec/22 ] |
|
Author: {'name': 'ali-mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}Message: (cherry picked from commit 9d47a813c02607ff8fb4fbc50b544ebeb494ce85) |
| Comment by Githook User [ 23/Aug/22 ] |
|
Author: {'name': 'ali-mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}Message: |
| Comment by Ali Mir [ 18/Apr/22 ] |
|
To start, we will change the assertion for the totalInitialSyncElapsedMillis to be greater than or equal to zero to reduce evergreen redness. |
| Comment by Ali Mir [ 18/Apr/22 ] |
|
In the initial syncer, we use exec->now() for the initialSyncStart, and Date_t::now() for the elapsed duration. We are repurposing this ticket to modify the assignment of the elapsed duration to use the task executor clock, which should stop the failing test from relying on real time. |
| Comment by Ali Mir [ 13/Apr/22 ] |
|
Putting back into Needs Triage so we can discuss the best course of action as a team. Currently, we have consistent duplicates of this BF on enterprise-macos-rosetta-2 and enterprise-macos-arm64. I don't immediately think there is a bug with retrieving a time value in macOS, since we appear to still use the gettimeofday system call (same as other non-Windows operating systems). |
| Comment by Ali Mir [ 13/Apr/22 ] |
|
The fix for this ended up being a little tricky. We calculate the elapsed time for initial sync by first setting the initialSyncStart, and then during progress reporting, get the elapsedDurationEnd. We then find the difference of these values to report the totalInitialSyncElapsedMillis. The linked BF occurred because this test ran very fast, and so the elapsed time was cast to be 0 milliseconds. Initially, I thought we could advance the network clock so that the elapsed time would always be greater than 0, but then I realized this defeats the purpose of the assertion, since we won't be testing anything if the value is always greater than 0. |