Skip to content

Conversation

ktoso
Copy link
Contributor

@ktoso ktoso commented Oct 9, 2025

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.

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.
@ktoso ktoso requested a review from glbrntt October 9, 2025 00:32
init(_ request: HTTPClientRequest, dnsOverride: [String: String] = [:]) throws {
init(
_ request: HTTPClientRequest,
tracing: HTTPClient.TracingConfiguration? = nil,
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Collaborator

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).

Copy link
Contributor Author

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 :)

@ktoso ktoso added the 🔨 semver/patch No public API change. label Oct 9, 2025
//===----------------------------------------------------------------------===//

@_spi(Tracing) import AsyncHTTPClient // NOT @testable - tests that need @testable go into HTTPClientInternalTests.swift
@_spi(Tracing) @testable import AsyncHTTPClient
Copy link
Collaborator

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?

Copy link
Contributor Author

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?

Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants