Ability to use a single interceptor for both unary and streaming RPCs #1805
Comments
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: Requirements:
Nice to Haves:
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.
|
Nice to Have, for Interceptors redesign: extract |
@dfawley wondering any news on new interceptor design, when it will be available, looking forward to single interceptor for both unary and streams.. |
For the moment, there are no plans to work on this, as there are just too many other, higher-priority things on our plate. However, when investigating how to support the xDS protocol for gRPC-LB v2 (ref), it's appearing that interceptors could play a prominent role. If that turns out to be the case, we may be able to do some or all of this work as part of that effort. |
Thank you @dfawley |
This issue is labeled as requiring an update from the reporter, and no update has been received after 7 days. If no update is provided in the next 7 days, this issue will be automatically closed. |
@dfawley, I think stale bot got it wrong on this one, too. I see this is "on hold", but probably should not be closed -- AFAICT, it is not pending any further input from the reporter(s). |
Yeah, it hit a lot of issues this morning. It doesn't seem to be listening to the "onlyLabels" setting (or we set it wrong). |
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.
The text was updated successfully, but these errors were encountered: