[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:
Backports
Depends
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: SERVER-65177 Use executor clock to calculate elapsed initial sync time

(cherry picked from commit 9d47a813c02607ff8fb4fbc50b544ebeb494ce85)
Branch: v6.0
https://github.com/mongodb/mongo/commit/198cd42e240e7ae8d2cc06250dccb67deda169ad

Comment by Githook User [ 08/Dec/22 ]

Author:

{'name': 'ali-mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}

Message: SERVER-65177 Use executor clock to calculate elapsed initial sync time

(cherry picked from commit 9d47a813c02607ff8fb4fbc50b544ebeb494ce85)
Branch: v5.0
https://github.com/mongodb/mongo/commit/d4b0442a5b0ddf6351940c3722908a88ac1de181

Comment by Githook User [ 23/Aug/22 ]

Author:

{'name': 'ali-mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'}

Message: SERVER-65177 Use executor clock to calculate elapsed initial sync time
Branch: master
https://github.com/mongodb/mongo/commit/9d47a813c02607ff8fb4fbc50b544ebeb494ce85

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.

Generated at Thu Feb 08 06:02:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.