googleapis: DirectPath over Interconnect by shivaspeaks · Pull Request #12760 · grpc/grpc-java (original) (raw)

The following changes are made outside of the design doc specifications or assuming few things:

• Node ID Suffix and UUID Size: While the design document suggests a 64-bit integer for the UUID, this PR maintains the existing 32-bit int (generated via Random().nextInt()) to remain consistent with the current implementation's ID generation logic.
• Ampersand Decoding (%26): The resolver now utilizes getRawQuery() instead of getQuery() for detecting and stripping the force-xds flag. This approach prevents a "splitting bug" where an encoded ampersand (%26) in a parameter value would be decoded to a literal & and incorrectly interpreted as a parameter separator.
• Separate Locks for Bootstrap Caching: I have introduced separate locks (BOOTSTRAP_LOCK and FORCE_XDS_BOOTSTRAP_LOCK) for managing the standard and forced xDS bootstrap configurations. This provides logical isolation and ensures that Interconnect clients using force-xds can initialize immediately without being blocked by threads waiting on potentially slow metadata server calls in the standard GCP detection path.
• URI Normalization via io.grpc.Uri: Even in the legacy java.net.URI constructor, we now use io.grpc.Uri to perform the transformation. This ensures consistent behavior across both constructors, particularly regarding "empty" vs "absent" authorities. Using the gRPC-specific Uri class ensures that hierarchical URIs like google-c2p:///svc (empty authority) are correctly reconstructed as dns:///svc or xds://.../svc rather than being mangled into invalid formats.
• Flexible Query Param Value Handling and Case Sensitivity for force-xds: The implementation treats the force-xds parameter key as case-sensitive to align with standard gRPC naming conventions. However, it provides flexible support for different value formats: the resolver recognizes both the standalone flag (?force-xds) and explicit key-value pairs like ?force-xds=true or ?force-xds=1. To avoid misinterpretation, the logic explicitly returns false only when the value is a case-insensitive match for "false" or is exactly "0", ensuring that common truthy values like true or 1 are correctly handled as enabled