Open daniel-sanche opened 10 months ago
@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
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