-
Notifications
You must be signed in to change notification settings - Fork 777
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: context activation for HTTP instrumentation's outgoing requests #2037
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2037 +/- ##
==========================================
+ Coverage 92.98% 93.06% +0.07%
==========================================
Files 152 153 +1
Lines 5934 5983 +49
Branches 1247 1257 +10
==========================================
+ Hits 5518 5568 +50
+ Misses 416 415 -1
|
I don't think that I think the span for the outgoing request should be set as active for the This would fix the issue with net (and most likely also dns) instrumentation without changing the whole span tree. |
|
What's wrong in issuing a followup operation already in |
Nothing wrong with that, it's a question of which context to activate in the response callback. The outgoing request context needs to be made available in at least one location. This is not related to |
I disagree that in your original example the current behavior is incorrect. If I make a request to |
Perhaps, but in a sense isn't the outgoing context lost forever then? |
It's at least serialized by My expectation on the span tree are as follows. Assume an incoming http request which does two outgoing and remote process is also monitored:
I'm not 100% sure if DnsLookup should be a child of NetConnect but I think it should. |
It is picked up by inject indeed, but if I wanted to add attributes to the outgoing span? |
That sounds like a usecase for something like the |
We talked about this at the SIG meeting today and the current behavior is the desired behavior. I am going to close this PR for now. If you disagree you can comment here and it could be reopened if there is reason to do so. |
In any case I'll modify it so the |
I am wondering if it would be useful to introduce |
It could be but this is a separate issue |
Are you going to modify this PR or open a new one for that? |
I'll open a new one |
Which problem is this PR solving?
A while ago context activation was removed from outgoing HTTP requests due to wrong context being activated, here: #1546
However with
net
module instrumentationconnect
spans were attached to the parent span of the request, which is wrong. Besides the wrong context (parent) context was being activated in the response callbacks (data
event) even if the response was not yet finished this made it impossible accessing the outgoing request span inside the response callbacks (e.g. when processing data chunks).Short description of the changes
Before
After
Example: chaining outgoing requests for an incoming request
Which will produce a trace similar to this (
net
instrumentation is enabled here, thus theconnect
spans):Remarks
@opentelemetry/context-async-hooks
, however I decided not to request a change toContextManager
interface of@opentelemetry/api
to add abind
method which instead of taking in a context, takes in a function which returns a context and opted for some code duplication. This is useful for event emitters which might require different contexts being activated based on the events.