-
Notifications
You must be signed in to change notification settings - Fork 51
fix: Capture potential missing tail data for session trace #624
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## main #624 +/- ##
==========================================
+ Coverage 69.94% 69.95% +0.01%
==========================================
Files 134 134
Lines 5995 5988 -7
Branches 1141 1139 -2
==========================================
- Hits 4193 4189 -4
+ Misses 1487 1486 -1
+ Partials 315 313 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Asset Size ReportMerging this pull request will result in the following CDN asset size changes:
Merging this pull request will result in the following NPM package consumer size changes:
Other Standard CDN AssetsReleased Assets
Built Assets
Other Polyfill CDN AssetsReleased Assets
Built Assets
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 assuming tests pass
I verified the safari tests that failed in github actions are passing locally. They appear to just be flakey. |
Send buffered session trace data in certain cases when it's being discarded at the tail end of a captured session.
Overview
In the old session trace behavior, it had discarded or not sent remaining session trace nodes when it hit the max duration life of the feature, even though the nodes were added before the max duration time. Likewise, on EoL of the page, session trace would not run final harvest if the buffered nodes is less than the required minimum of 30, which causes that valid data to be amiss. This PR patches both of those issues.
Related Issue(s)
NR-138555
Testing
Workflows listed in bug ticket's AC list should hold true, namely: