Call interceptors#1218
Merged
Merged
Conversation
Fixes #1197 Co-Authored-By: Michael Dowling <michael@mtdowling.com>
…s in call decorators
…ow access in call decorators" This reverts commit 72dc964.
CallDecorator can compose in onion order via CallDecorator.chain, and plugins register them additively with addCallDecorator so multiple plugins can layer behavior without clobbering each other. Decorators receive a ClientCallView, a read-only handle to the resolved call (input, operation, merged context, endpoint resolver, type registry, auth scheme resolver and schemes, identity resolvers). The view is implemented by the existing package-private ClientCall, so no extra allocation per call. Override merging and modifyBeforeCall now happen up-front in buildCall, so RequestOverrideConfig stops leaking into the public decorator surface and decorators see the same effective context as interceptors.
Instead of a separate CallDecorator abstraction, unify call interception into ClientInterceptors using a new interceptCall hook and interceptCalls boolean method. If interceptCalls returns true, then the interceptors is used in a chain of middleware-style interceptors that can completely intercept control flow of the call. This can be used for things like caching, hedging, etc. A tradeoff of making this an interceptor hook vs a dedicated abstraction is that the Client, if needed, is not generic and instead stashed in Context. The cost for making calls is essentially the same when nothing intercepts. The cost of actually intercepting is essentially the same (one pre-resolves the chain in a nested call stack, this is iterative). The advantages are that there's a single abstraction and composition is the same as before.
timocov
approved these changes
May 27, 2026
adwsingh
approved these changes
May 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces #1211, Closes #1197
Instead of a separate CallDecorator abstraction, unify call interception
into ClientInterceptors using a new interceptCall hook and
interceptCalls boolean method. If interceptCalls returns true, then
the interceptors is used in a chain of middleware-style interceptors
that can completely intercept control flow of the call. This can be
used for things like caching, hedging, etc.
A tradeoff of making this an interceptor hook vs a dedicated abstraction
is that the Client, if needed, is not generic and instead stashed in
Context. The cost for making calls is essentially the same when nothing
intercepts. The cost of actually intercepting is essentially the same
(one pre-resolves the chain in a nested call stack, this is iterative).
The advantages are that there's a single abstraction and composition
is the same as before.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.