[kalragauri]

Currently, transport_type on the channel_creation_latency metric and in the channel-ready log line is inferred from the configured endpoint via DetectTransportType(), so it reports whatever the endpoint asked for. At runtime the google-c2p resolver can fall back to DNS, for example on hosts that gRPC does not detect as GCE VMs, and gRPC < 1.85.0 ignores the force-xds query parameter. Channels that were in fact using DNS (CloudPath) were therefore labeled DirectPath or DirectPathInterconnect.

ChannelReadyWaiter now reads the channel's load-balancing policy via grpc::Channel::GetLoadBalancingPolicyName() when the wait for the first channel ends, and once the channel is ready SelectedTransportType() corrects the requested transport:

• pick_first means google-c2p fell back to DNS, and the label becomes CloudPath. It is gRPC's default policy, and therefore what a DNS result produces for this library.
• Otherwise, on gRPC < 1.85.0, DirectPathInterconnect becomes DirectPath, because force-xds is ignored.

Only two policy names are interpreted: pick_first as DNS, and xds_cluster_manager_experimental, the top-level policy of every xDS resolver result (gRFC A31), as xDS. Any other name, including an empty one, is treated as unknown: the label stays at the requested transport (still adjusted for an ignored force-xds) and, for DirectPath requests, the ready line says so.

Both the channel_creation_latency metric callback and LogChannelReady receive the corrected value. The transport_type label name and its values (CloudPath, DirectPath, DirectPathInterconnect) are unchanged.

The log lines now distinguish the requested transport from the corrected one:

• LogChannelConfiguration logs requested_transport_type= (renamed from transport_type=) and adds grpc_version= to the startup INFO line.
• LogChannelReady logs transport_type=, requested_transport_type=, lb_policy=, and elapsed_ms= when the channel becomes ready, with a note explaining a DNS fallback, an ignored force-xds, or an unrecognized LB policy.

[gemini-code-assist]

Code Review

This pull request refactors the gRPC channel telemetry to distinguish between the requested transport type and the actual transport type selected by gRPC at runtime. It introduces helper functions to classify load balancing policies and determine the selected transport, updating the logging and telemetry callbacks accordingly. Feedback is provided to optimize the retrieval of the channel ready outcome in StartChannelTelemetry by moving the value out of the future to avoid an unnecessary copy of non-fundamental types.

[codecov]

Codecov Report

❌ Patch coverage is 97.12230% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.38%. Comparing base (bca2305) to head (db626f3).

Files with missing lines	Patch %	Lines
...e/cloud/storage/internal/grpc/channel_telemetry.cc	96.66%	2 Missing ⚠️
...ud/storage/internal/grpc/channel_telemetry_test.cc	97.46%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #16568      +/-   ##
==========================================
- Coverage   92.39%   92.38%   -0.02%     
==========================================
  Files        2266     2266              
  Lines      219636   219732      +96     
==========================================
+ Hits       202938   203002      +64     
- Misses      16698    16730      +32     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[v-pratap]

LGTM — nice fix and thorough test coverage across the DNS fallback, ignored force-xds, and unrecognized LB policy cases.