-
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(pg): update requireParentSpan to skip instrumentation when parent not present #1343
Merged
blumamir
merged 4 commits into
open-telemetry:main
from
ryan-codaio:pg-fix-requireParentSpan
Feb 7, 2023
Merged
fix(pg): update requireParentSpan to skip instrumentation when parent not present #1343
blumamir
merged 4 commits into
open-telemetry:main
from
ryan-codaio:pg-fix-requireParentSpan
Feb 7, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #1343 +/- ##
==========================================
- Coverage 96.08% 95.82% -0.26%
==========================================
Files 14 18 +4
Lines 893 1221 +328
Branches 191 263 +72
==========================================
+ Hits 858 1170 +312
- Misses 35 51 +16
|
Hi, would I be able to get a review on this PR? Thanks in advance! |
blumamir
approved these changes
Feb 5, 2023
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.
LGTM
sorry about the time it took to review
plugins/node/opentelemetry-instrumentation-pg/test/pg-pool.test.ts
Outdated
Show resolved
Hide resolved
Thank you so much for the review! |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Which problem is this PR solving?
I previously added a
requireParentSpan
config flag that can be used to suppress instrumentation if there is no active trace (see #1199). The implementation created a no-op span, imitating the implementation for the requireParent flags in instrumentation-http, then continued running instrumentation code as usual.This doesn't seem to be working well in practice. There are cases where the pg instrumentation creates a (no-op) span, then does something else that tries to create another span. The second invocation sees that a parent span exists, so it creates a real span. But this span is created as a sibling of the no-op span, not as a child, so then it gets emitted as a real trace. For example, I saw cases where BoundPool.connect created a (no-op) span and then called Client.connect, which saw an existing span in the context and subsequently created a (real) span.
I considered modifying
startSpan
to create real spans as children of whatevercurrentSpan
was returned bytrace.getSpan(context.active())
; that way, the spans would get dropped as children of a no-op span. But it doesn't look like other opentelemetry instrumentation libraries do this often. I'm not very familiar with opentelemetry so I'm not sure if this is the right thing to do. It seems like a context can have multiple sibling spans, so it seems like making the span a child oftrace.getSpan(context.active())
could end up creating a span as a child of the wrong parent span?Short description of the changes
I changed the
requireParentSpan
implementation to avoid running instrumentation on calls when a parent span is required but doesn't exist. This way, no span is created at all. This matches the implementation in instrumentation-ioredis.