-
Notifications
You must be signed in to change notification settings - Fork 508
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
tls instrumentation in @opentelemetry/instrumentation-net
tries to operate on closed span
#1775
Comments
Thanks for reporting this! I'm not in-depth familiar with this instrumentation but it looks like if option 1 can be done without it impacting the way currently exported telemetry looks, I'd prefer it. 🙂 Assigning p4 as it's primarily logspam; am I right with that assumption?- or are you also seeing that the exported span is incorrect? That would bump it to p2. |
Yes, that's what it looks like; since the span is closed anyway, it couldn't have been changed by the existing behaviour. Bigger-picture, it may be preferable to have the error on some span. I don't currently recall if that's the existing case. I'll PR soon enough to implement the behaviour, it's a simple one-liner.
That's correct, it's slightly annoying when reading logs, but nothing bigger than that. Thanks! |
Hello guys, has this fix made it into the latest releases? Thanks. |
@ccoqueiro It should be available now in v0.32.4. In case it helps, I found this by clicking to the PR and clicking on the commit that merged into Main. That shows the tags that contain this commit. Contrast that with a commit from a more recent PR, it will only show main and not other tags. Hope this helps! |
What version of OpenTelemetry are you using?
@opentelemetry/[email protected]
@opentelemetry/[email protected]
What version of Node are you using?
Reproduced on:
What did you do?
When instrumented code uses
fetch
in a non-idiomatic manner, the tls instrumentation attempts to do an action on a closedtls.connect
span.For example, instrumenting the following code:
The
fetch
timeouts since the response is not properly handled.Point
A
is called when theCONNECT
event is emitted, handled inside otel here:opentelemetry-js-contrib/plugins/node/opentelemetry-instrumentation-net/src/instrumentation.ts
Lines 122 to 143 in de6156a
Point
B
is called when theERROR
event is emitted, handled here:opentelemetry-js-contrib/plugins/node/opentelemetry-instrumentation-net/src/instrumentation.ts
Lines 145 to 151 in de6156a
First
A
is emitted, setting some attributes andend
ing the span. ThenB
is hit, which attempts to set a status and close the span. That's invalid, since the span has already ended. WithOTEL_LOG_LEVEL
set toinfo
, it prints something like the following:What did you expect to see?
The tls instrumentation handles these scenarios without stepping on its own toes.
What did you see instead?
When a
fetch
timeouts, the tls instrumentation tries doing operations on an ended spanPossible solutions
A couple of options (of course, more are possible):
connect
handlertls.connect
is a child span. Subsequent errors hit the longer parent spanI'm more than willing to create a followup PR for this
The text was updated successfully, but these errors were encountered: