-
Notifications
You must be signed in to change notification settings - Fork 534
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
fix(instrumentation-runtime-node): use TestMetricReader, unref timer #1965
fix(instrumentation-runtime-node): use TestMetricReader, unref timer #1965
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #1965 +/- ##
==========================================
- Coverage 91.03% 90.97% -0.06%
==========================================
Files 146 146
Lines 7492 7492
Branches 1501 1502 +1
==========================================
- Hits 6820 6816 -4
- Misses 672 676 +4
|
plugins/node/instrumentation-perf-hooks/test/event_loop_utilization.test.ts
Outdated
Show resolved
Hide resolved
@pichlermarc thanks for cleaning up these tests, they look much sturdier now
Good call 👍 |
await new Promise(resolve => setTimeout(resolve, MEASUREMENT_INTERVAL * 5)); | ||
const { resourceMetrics, errors } = await metricReader.collect(); | ||
|
||
// assert |
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.
TIL: the arrange-act-assert pattern name (http://wiki.c2.com/?ArrangeActAssert)
Which problem is this PR solving?
1
(fix(instr-perf-hooks): avoid 'prepare' npm script because that runs on 'npm install' #1955) . This might have happened as the collection happened at a time where event loop was fully utilized. This PR attempts to fix this by doing two things:PeriodicExportingMetricReader
to avoid having to wait for collection, getting rid of one variable that might break tests<=1
as a value as it's a valid value for a fully utilized event loop (which can happen in some cases as collection does not need to wait for anything that's not doing work on the event loop).disable()
was never called when the test failed. I can see this happening in apps too as it's rather uncommon todisable()
instrumentations before shutting down. Therefore inunref
ed the timer when it's created.Fixes #1960