[trask]

Populate gRPC client server.address and server.port from configured channel targets rather than channel authority alone.

Library users can supply the target explicitly on all supported gRPC versions, without depending on gRPC's internal target-aware interception API:

GrpcTelemetry telemetry = GrpcTelemetry.create(openTelemetry);
String target = "dns:///orders.example.com:8443";
ManagedChannelBuilder<?> channelBuilder = ManagedChannelBuilder.forTarget(target);
channelBuilder.intercept(telemetry.createClientInterceptor(target));

The no-argument createClientInterceptor() continues to use channel authority. For custom name resolvers, use an explicit scheme://... target.

For automatic capture, use this experimental API instead of registering the interceptor directly:

Experimental.addClientInterceptor(telemetry, channelBuilder);

Experimental is in io.opentelemetry.instrumentation.grpc.v1_6.internal. Automatic capture depends on gRPC's internal API on 1.64.0 and newer, falling back to authority on older versions or unsupported builders. The Java agent uses this automatic path.

Remove GrpcRequest.getLogicalHost() and getLogicalPort() for 3.0. Use getServerAddress() and getServerPort() instead. getServerPort() returns null rather than -1 when the port is unavailable.

[lmolkova]

Looks great (assuming you're comfortable depending on '@internal public' API)

[Copilot]

Copilot review overview

🟡 Changes recommended

Numeric opaque targets for custom resolver schemes are incorrectly emitted as host-and-port values.

Review effort: Balanced
Findings: 1

Open (1)

• Preserve numeric opaque custom resolver targets · New

Resolved since last review (1)

• Strip URI userinfo before recording gRPC server address

[Copilot]

Copilot review overview

🟡 Changes recommended

Raw hostname-and-port targets are misclassified as resolver schemes, producing incorrect server attributes.

Review effort: Balanced
Findings: 1

Open (1)

• Javaagent misparses hostname:port targets and omits server.port · New

Resolved since last review (1)

• Preserve numeric opaque custom resolver targets

[Copilot]

Copilot review overview

🟡 Changes recommended

IPv6 Armeria targets and per-builder custom resolvers currently produce incorrect endpoint attributes.

Review effort: Balanced
Findings: 2

Open (2)

• IPv6 URI targets fail to parse address and port · New
• Per-builder resolver selection is lost during target parsing · New

Resolved since last review (1)

• Javaagent misparses hostname:port targets and omits server.port

[Copilot]

Copilot review overview

🔵 Needs a closer look

The javaagent misclassifies raw targets for channels using per-builder custom resolvers.

Review effort: Balanced
Findings: None

Resolved since last review (2)

• Per-builder resolver selection is lost during target parsing
• IPv6 URI targets fail to parse address and port

Previously missed (1)

In code that hasn't changed since last review

Use the builder's resolver when parsing gRPC targets

instrumentation/​grpc-1.6/​javaagent/​src/​main/​java/​io/​opentelemetry/​javaagent/​instrumentation/​grpc/​v1_6/​GrpcClientBuilderBuildInstrumentation.java:50

[Javaagent] This passes the builder's raw target to a parser that consults only the global NameResolverRegistry, but gRPC supports a per-builder resolver via nameResolverFactory(...). For example, a builder whose custom resolver owns consul:1234 computes that custom target, while this path sees no global consul provider and emits server.address="consul" and server.port=1234 instead of preserving consul:1234 with no port. Install the target-aware interceptor factory on the builder (so gRPC supplies its computed target) or carry the builder's resolver selection into parsing; on older gRPC versions, authority fallback is safer than misclassifying the raw target.

[Copilot]

Copilot review overview

🟢 Approval recommended

Target parsing, compatibility fallbacks, API migration, and integration coverage are consistent and complete.

Review effort: Balanced
Findings: None

[Copilot]

🔵 Needs a closer look

Reflective interception across supported gRPC versions and Armeria integration warrants final human compatibility review.

No open issues 🎉

_{Review effort: Balanced}

[github-actions]

⚠️ Breaking Change Documentation Required

This PR has been labeled as a breaking change. Please ensure you provide the following information:

Migration Notes Required

Please add detailed migration notes to help users understand:

• What is changing and why
• How to update their code/configuration
• Any alternative approaches if applicable
• Code examples showing before/after usage

Checklist

• Migration notes added to the PR description
• Breaking change is documented in the "Unreleased" section of the Changelog, preferably as part of this PR.
• Consider if this change requires a major version bump

Your migration notes will be included in the release notes to help users upgrade smoothly. The more detailed and helpful they are, the better the user experience will be.

---

This comment was automatically generated because the breaking change label was applied to this PR.

[trask]

/dashboard route:reviewers

[opentelemetry-pr-dashboard]

@trask, your reviewer-routing request was recorded; this pull request has the approvals it needs and is now waiting on maintainers. The handoff remains active across pushes until newer actionable human feedback arrives. Top-level feedback through this request will not return; unresolved review threads remain open.