[SERVER-36361] Round timeOpenMicros to have millisecond precision for assertions that use ISODate Created: 30/Jul/18  Updated: 29/Oct/23  Resolved: 02/Aug/18

Status: Closed
Project: Core Server
Component/s: Diagnostics, Replication
Affects Version/s: None
Fix Version/s: 4.1.2

Type: Bug Priority: Major - P3
Reporter: Jinny Byun Assignee: Jinny Byun
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
is caused by SERVER-35302 Add startWallClockTime to the transac... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Participants:
Linked BF Score: 13

 Description   

Currently, in aggregation_currentop.js, an assertion to check that timeOpenMicros is greater than timeBeforeCurrentOp - timeAfterTransactionStarts fails sometimes. This is because timeOpenMicros is a server-side metric with microsecond precision whereas timeBeforeCurrentOp and timeAfterTransactionStarts are ISODates with only millisecond precision. The discrepancy in precision causes rounding issues, so the assertion occasionally fails (ex. 2966 is not greater than 3000). We should round timeOpenMicros to have millisecond precision instead.



 Comments   
Comment by Githook User [ 15/Aug/18 ]

Author:

{'username': 'jinichu', 'email': 'jinnybyun@gmail.com', 'name': 'jinichu'}

Message: SERVER-36361 Round timeOpenMicros to have millisecond precision for assertions that use ISODate

(cherry picked from commit 5e97e5813e7ad1127d79454e52fcfe49ed129096)
Branch: v4.0
https://github.com/mongodb/mongo/commit/8508be801e3ed6552bbe962c7cc3f9940e748cf8

Comment by Githook User [ 02/Aug/18 ]

Author:

{'name': 'jinichu', 'email': 'jinnybyun@gmail.com', 'username': 'jinichu'}

Message: SERVER-36361 Round timeOpenMicros to have millisecond precision for assertions that use ISODate
Branch: master
https://github.com/mongodb/mongo/commit/5e97e5813e7ad1127d79454e52fcfe49ed129096

Generated at Thu Feb 08 04:42:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.