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

Ability to use a single interceptor for both unary and streaming RPCs #1805

jhump opened this Issue Jan 17, 2018 · 2 comments


None yet
3 participants

jhump commented Jan 17, 2018

After #1801 is completed, it becomes possible for a stream interceptor to be used when processing unary RPCs.

This issue is a feature request for some new API that allows for exactly this. The existing API, for backwards compatibility, will continue to register a stream interceptor that is only used for streaming RPCs. But a new method/dial option could be added that allows for registering a stream interceptor that is used for unary RPCs and/or for both streaming and unary RPCs.


This comment has been minimized.


dfawley commented Mar 15, 2018

I'd like to redesign our interceptor API. Please add your list of requirements/nice-to-haves in this bug and I'll compile them here:


  • Single interceptor type for unary and streaming
    • If it's difficult to implement, provide an optional convenience wrapper to generate a stream-style interceptor from a single function (like how unary interceptors work today).
  • Include access to ServiceDesc/FileDescriptorProto (#1526)
  • Chainable / able to easily register multiple handlers

Nice to Haves:

  • Single API for stats handlers and interceptors
  • Global registration pattern
  • Able to specify via CallOptions
  • Function signature includes explicit context.Context (from @skipor)
  • Same/similar type signature as RPC handler itself (Java does this)

This is currently just a quick list based on my memory at the moment. I intend to add to this as I run into more things.

This will be a breaking change (breaking only features marked "EXPERIMENTAL" in the docs), but we will make sure to leave the current version around for one or two releases to allow time for users to migrate. We will also be sure to make a gRFC proposal for this.


This comment has been minimized.

skipor commented Apr 24, 2018

Nice to Have, for Interceptors redesign: extract context.Context from ServerStream and pass it as the first argument in stream interceptor.
Now every context.Context wrapping requires also ServerStream wrapping, which is too complex. In my experience Context wrapping with value or timeout is a very common pattern, and it would be really nice to use it as everywhere else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment