RUM-3458: Fix time drift in RecordedDataQueueHandler#2075
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #2075 +/- ##
===========================================
- Coverage 83.19% 83.16% -0.03%
===========================================
Files 495 495
Lines 17773 17752 -21
Branches 2685 2684 -1
===========================================
- Hits 14785 14762 -23
+ Misses 2256 2250 -6
- Partials 732 740 +8
🚀 New features to boost your workflow:
|
e4fa696 to
9799a02
Compare
0xnm
left a comment
There was a problem hiding this comment.
lgtm. Since we care only about item age at this point, using 2 System.nanoTime() instants is fine and result of this call is monotonically increasing.
However, there is a second timestamp involved, which is attached to the queue item and then used later to build wireframes (nextItem.recordedQueuedItemContext.timestamp), so it is better to have another pair of eyes for the review here, because I'm don't have a deep knowledge of the whole processing pipeline.
| internalLogger = internalLogger, | ||
|
|
||
| /** | ||
| * TODO RUMM-0000 consider change to LoggingThreadPoolExecutor once V2 is merged. |
There was a problem hiding this comment.
I think it is time to do it: it is a simple change and can be made in another PR
9799a02 to
5e3f8b3
Compare
What does this PR do?
Fixes an issue in the RecordedDataQueueHandler where the "current" time was being passed in to the loop, but never updated inside it. This could lead to the time drifting when the queue was very long, leading to items being considered out of date.
Motivation
We have telemetry indicating numerous DataQueueItems are being dropped for being out of date.
Additional Notes
Anything else we should know when reviewing?
Review checklist (to be filled by reviewers)