Modify httpclient instrumentation to take advantage of sampling decision #1894
Conversation
| // By this time, samplers have already run and | ||
| // activity.IsAllDataRequested populated accordingly. | ||
|
|
||
| if (Sdk.SuppressInstrumentation) |
There was a problem hiding this comment.
this check is done to make sure to have no side-effect if under supression. Even without this, TracerProviderSdk drops the activity if under supressions, but this method does propagation. This check prevents every side effect including propagation if under suppression.
Codecov Report
@@ Coverage Diff @@
## main #1894 +/- ##
==========================================
+ Coverage 83.33% 83.35% +0.02%
==========================================
Files 188 188
Lines 6137 6139 +2
==========================================
+ Hits 5114 5117 +3
+ Misses 1023 1022 -1
|
| if (!this.startRequestFetcher.TryFetch(payload, out HttpRequestMessage request) || request == null) | ||
| { | ||
| HttpInstrumentationEventSource.Log.NullPayload(nameof(HttpHandlerDiagnosticListener), nameof(this.OnStartActivity)); | ||
| return; | ||
| } | ||
|
|
||
| // TODO: Investigate why this check is needed. |
There was a problem hiding this comment.
I think it was put for redirection cases where a redirect request might already have the context in the headers.
But I don't think the listener callback gets called for redirect cases. I tried this scenario: Call http://google.com from an HttpClient. This results in a 301 redirection to http:www.//google.com. The way HttpHandlerDiagnostics is currently configured, we only see one OnStartActivity and one OnStopActivity method call.
In the OnStartActivity method they request payload has the original Uri: http://google.com whereas in the OnStopActivity method the payload has the redirected Uri: http:www.//google.com. This would mean that we only enter OnStartActivity once for the original HttpRequestOut call. So this logic would not be used for redirects.
There was a problem hiding this comment.
I know there were cases when I was working on HttpWebRequest instrumentation where it would re-use the request, but it has been a while so my memory is foggy. I think SSL upgrade/downgrade was one of them? Pretty sure I added a test or two for it. That is for the .NET Framework stuff but posting here because there are probably many similarities with the .NET Core side.
Just a single instrumentation in this PR. More instrumentations can leverage similar optimization.
Follows #1893
Changes
Please provide a brief description of the changes here.
For significant contributions please make sure you have completed the following items:
CHANGELOG.mdupdated for non-trivial changes