feat(transport/grpc): add function to get reason for direct path incompatibility#3491
feat(transport/grpc): add function to get reason for direct path incompatibility#3491cpriti-os wants to merge 9 commits intogoogleapis:mainfrom
Conversation
|
@cpriti-os Why is this component here in https://github.com/googleapis/google-api-go-client/tree/main/transport/grpc and not for example in the newer equivalent package https://github.com/googleapis/google-cloud-go/tree/main/auth/grpctransport ? |
Thanks for pointing out, couldn't find it when I raised this, will try to move the code there. |
I was checking the storage dependencies and I dont think the storage package uses the new auth library, therefore adding the change there will not help us get the reason in storage layer without migrating. |
| } | ||
| } | ||
|
|
||
| func TestIsDirectPathEnabled(t *testing.T) { |
There was a problem hiding this comment.
Are these tests relevant to the changes?
There was a problem hiding this comment.
Earlier this particular test was since I was reusing this function in the logic I added and its good to be covered. Didn't see the harm in keeping the test even if logic was updated to be more granular
shollyman
left a comment
shollyman
left a comment
There was a problem hiding this comment.
I'm still a bit confused a bit by how this code is intended to be leveraged, given the mix of resolving dial options, checking resolved grpc, and resolving auth configuration. Is there a doc that can help me understand this a bit better? We've had a few similar requests recently around complexities resolving client options, and I'm trying to figure out if there's common functionality we should be building out. This very detailed exported function that appears to rationalize why a behavior didn't happen, and I wonder if we can simplify it with some underlying designs.
@shollyman thank you for checking this. Our current goal is pretty simple, provide as granular a reason as possible as to why the client chose not to use Direct Path. The added function would be called by GCS Go SDK while creating a new gRPC client and pass the received reason to the backend using headers. The backend can then log this telemetry and in the near future reject a cloudpath request with the reason (in this PR) to help customer resolve the issue more efficiently. I have also provided a one pager discussing this in the chat space. Let me know if this answers the question. Happy to discuss more. |
4 participants
Adds DirectPathStatus and CheckWithReason to categorize why DirectPath is used or disabled into fallback reasons. This enables better observability.