Conversation
|
CC @liyanhui1228 For an opinion on how this looks from the perspective of a contributor to OpenCensus. See #1 (comment) and the following conversation for context on this discussion. |
cc @c24t for OpenCensus Python |
| """ | ||
| # NOTE: The return type here closely mirrors the original | ||
| # GenericClientInterceptor interface. We may want to clean it up. | ||
| def intercept_call(client_call_details: grpc.aio.ClientCallDetails, |
| client_call_details.credentials) | ||
| return new_client_call_details, request_generator, None | ||
|
|
||
| return grpc.aio.generic_client_interceptor(intercept_call) |
There was a problem hiding this comment.
just asking, generic_client_interceptor would provide a way for creating an interceptor without needing to implement a derivated interceptor class? does it exist in the current API?
|
|
||
| async def CreateUser(self, | ||
| request: user_pb2.CreateUserRequest, | ||
| context: grpc.aio.ServicerContext): |
There was a problem hiding this comment.
It would be nice to have also an example of how the timeout could be modified by the server evaluating the timeout provided by the context, for making a decision if the timeout needs to be modified or if it does not exist adding it.
| stack from server to client. But without middleware installed, *nothing* is | ||
| propagated by default, except timeout and cancellation, which are handled by the | ||
| gRPC library itself using `ContextVar` objects managed by the `gRPC` library | ||
| itself. |
4 participants
This PR is a an example illustrating a proposal for how to handle distributed context within the gRPC Python asyncio API.
@pfreixes
@lidizheng
@euroelessar