[Question] Valid to call super().intercept for method call handling in async

[chamini2]

I have the following interceptor

class AuthInterceptor(AsyncServerInterceptor):
    async def intercept(
        self,
        method: Callable,
        request: Any,
        context: async_grpc.ServicerContext,
        method_name: str,
    ):
        try:
            await auth_check(context)

            # Leave to pacakge the method handling
            return await super().intercept(method, request, context, method_name)

        except TypeError as err:
            raise GrpcException('\n'.join(err.args), grpc.StatusCode.UNAUTHENTICATED)
        except RuntimeError as err:
            raise GrpcException('\n'.join(err.args), grpc.StatusCode.UNAUTHENTICATED)

And it seems to work fine for the error and success cases I tested. It made sense to me since AsyncServerInterceptor does the

        response_or_iterator = method(request, context)
        if hasattr(response_or_iterator, "__aiter__"):
            return response_or_iterator
        else:
            return await response_or_iterator

thing where it decides how to handle the next method.

And it also made sense because a not-implemented interceptor should be a no-op

class NothingInterceptor(AsyncServerInterceptor):
  pass

---

Is this intended use to call the super().intercept and let it handle? Is this a bad idea?

[d5h]

Well, technically AsyncServerInterceptor.intercept is an abstract method which is not intended to be called. I gave it a default no-op implementation as an example. That said, I don't see any reason to change the example implementation. If you have a test for your interceptor, so you'll know if it ever breaks on update, then you'll be fine.

Now that you bring this up, it might make sense to make the default implementation non-abstract. I need to write some tests before committing to that, but maybe I'll make this the intended usage in the future.