Update gRPCContext wrapper class #420
Conversation
There are a few cases where one needs to dig into `grpc.ServicerContext` objects, and these fields were missing from our wrapper, which can cause issues with implmementation. Yes, they're private attributes, but there's no way to get the data they hold otherwise, so we should properly map them so our wrapper Context behaves like a real one does.
alertedsnake
requested review from
a team,
codeboten and
srikanthccv
and removed request for
a team
alertedsnake
changed the title
There was a problem hiding this comment.
Code looks good, is it worth adding a test around this? @alertedsnake
There was a problem hiding this comment.
I agree with the main objective of this PR, @alertedsnake, but please consider reimplementing this with __getattr__ instead of relying on private attributes.
| @@ -71,6 +71,30 @@ def __init__(self, servicer_context, active_span): | |||
| self.details = None | |||
| super().__init__() | |||
|
|
|||
| @property | |||
There was a problem hiding this comment.
Still, we should not use someone else's private attributes. Also, next time we need to access a private attribute we would need to add yet another property.
I feel like this is a job for __getattr__.
There was a problem hiding this comment.
I could agree with that, though since this class is a wrapper instead of a subclass, this is always going to be a problem when the wrapped class gets changed and people expect those changes to propagate. In fact, now that I look again, we're missing a private function as well, _finalize_state().
Not sure who the original author was, but I wonder why the choice was made to wrap this rather than subclass it? Possibly because the grpc implementation is also marked private.
(edited, after I refreshed my memory on how __getattr__ works) I'll try re-implementing this with your suggestion, but still curious about the original decision, if anyone knows the answer.
There was a problem hiding this comment.
Correct, use the wrapped attribute if the attribute is not found in the wrapper. 👍
There was a problem hiding this comment.
Oh I know the answer to my question - because the base class is a metadata class, the real class is that private _Context in the private grpc._server module.
Expect an update later today, and thanks for the tip!
Based on feedback from @ocelotl.
Description
There are a few cases where one needs to dig into
grpc.ServicerContextobjects, and these fields were missing from our wrapper, which can cause issues with implmementation.Yes, they're private attributes, but there's no way to get the data they hold otherwise, so we should properly map them so our wrapper Context behaves like a real one does.
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
There don't seem to be any test cases which cover this - I only noticed because I have an interceptor that reports exceptions to Sentry, and so it has to dig into the
grpc.ServicerContextobject for details, rather than wrapping it like we do here.Does This PR Require a Core Repo Change?
Checklist:
See contributing.md for styleguide, changelog guidelines, and more.