fix(transport/grpc): retain UserAgent option with new auth stack #2690
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The only code that converted the
option.WithUserAgent
to a gRPC DialOptionWithUserAgent
was in thedial
function, which was bypassed when leveraging the new auth library that handles most of the important dialing set up re:credentials.To fix this, I added a new helper specifically for use in
dialPoolNewAuth
that prepares dial options based on the givenDialSettings
-prepareDialOpionsNewAuth
. I could've added the same logic to anywhere indialPoolNewAuth
to fix it, but I felt I needed to signal that this is the method to be modifying gRPC DialOptions in so that in the future, we can centralize further gRPC DialOption manipulation rather than just "wherever" like in the "old"dial
.Also stored the
grpctransport.Dial
function into a global variable so that unit tests could spoof it to check on the gRPC DialOptions that were provided - just like the "old"dial
did for testing.Updates googleapis/google-cloud-go#10550 but needs to be released here, integrated there, and released there.