-
Notifications
You must be signed in to change notification settings - Fork 70
Support accessing trailing_metadata in unary functions #1856
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
priority: p2
Moderately-important priority. Fix may not be included in next release.
type: feature request
‘Nice-to-have’ improvement, new feature or different behavior or design.
Comments
@daniel-sanche , is this blocking your work in any way? Asking so we can prioritize this appropriately. |
For now I will be making patches to the bigtable library directly, so not completely blocked. But having it available in the upstream generator soon would definitely help make things go smoother |
Closing as obsolete as a solution is available using gRPC interceptors
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
priority: p2
Moderately-important priority. Fix may not be included in next release.
type: feature request
‘Nice-to-have’ improvement, new feature or different behavior or design.
Uh oh!
There was an error while loading. Please reload this page.
Most grpc calls return a
grpc.Call
object containing trailing metadata and other useful information. This object is exposed to gapic users in streaming rpcs, because it is part of the iterator object that is returned when the rpc is called. Unary gapic methods don't currently expose this in any way, so there is no way to access trailing metadata without going around gapicThere are a few ways we could surface the
grpc.Call
object:Synchronous
Option 1.
We can expose this in synchronous methods through a separete
*_with_call
method, which returns a tuple of the result data, and the Call object. This would align us with how the underlying grpc library handles the issue.Option 2
Alternatively, we could expose this through a callback that is passed in, if we want to keep the result type static
Either way, implementing this requires this change in the api-core repo(Merged)Async
Option 1
One way to address this is to return the Call object directly, instead of awaiting it as part of the function. This would force us to change all of our function signatures from "coroutine functions" into "sync functions that return a coroutine", but functionally it should be the same. (This is already how we handle the stream methods)
Option 2
Alternatively, we could follow the same format we choose for the Synchronous surface, to keep things consistent (i.e. either returning a tuple when a flag is set, or accepting a callback)
A callback could be a bit tricky convenient for async functions though, because we need to be an an async context to access any useful information on the Call object
or
or
or
The text was updated successfully, but these errors were encountered: