-
Notifications
You must be signed in to change notification settings - Fork 133
[Tracing] Implement trace header context propagation #862
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
base: main
Are you sure you want to change the base?
Conversation
Somewhere along the way of reviewing previous work this bit got lost; This implements context propagation by injecting the apropriate headers from service context into the headers when forming a `Prepared` http request.
init(_ request: HTTPClientRequest, dnsOverride: [String: String] = [:]) throws { | ||
init( | ||
_ request: HTTPClientRequest, | ||
tracing: HTTPClient.TracingConfiguration? = nil, |
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.
Nitpick: Shouldn't the non-optional dnsOverride argument go before the optional tracing one?
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.
Both are defaulted/optional. Could invert if @glbrntt thinks that'd be better tho hmm
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.
Isn't dnsOverride
a non-optional dictionary defaulting to empty? Again, very nitpick and feel free to ignore the comment.
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.
It's internal API so I don't mind either way, and neither requires the caller to set it explicitly so the order doesn't matter.
However, I would've put dnsOverride
before tracing
as the dnsOverride
is used for "core" functionality (i.e. actually making the request) vs. "extra" functionality (observability).
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.
ok i'll switch it :)
//===----------------------------------------------------------------------===// | ||
|
||
@_spi(Tracing) import AsyncHTTPClient // NOT @testable - tests that need @testable go into HTTPClientInternalTests.swift | ||
@_spi(Tracing) @testable import AsyncHTTPClient |
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.
The previous comment was there for a reason, so that internal API isn't accidentally used in these tests. Can you move the new test?
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.
Okey, should I perhaps make HTTPClientTracingInternalTests.swift then?
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.
Yeah, that seems like the right place
Somewhere along the way of reviewing previous work this bit got lost;
This implements context propagation by injecting the apropriate headers from service context into the headers when forming a
Prepared
http request.