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.
This PR introduces
QueryInterceptor
andBatchInterceptor
interfaces for intercepting queries immediately before execution, which allows clients to inject logic that should apply to all queries. My personal use case iscontext
manipulation and conditionally enabling cassandra tracing, but the interfaces could be used for rate limiting, query modification, logging, fault injection, metrics, etc.The approach here is similar to #1786, but intercepts at the higher query execution level rather than the query attempt/request level. I like the idea of intercepting attempts, but I think the nuances of request handling (retry policies, speculative execution, client side host selection) could lead to unexpected behavior. For example, rewriting and replacing a query via attempt interceptor would lose query retry metrics and violate the retry policy. Or rate limiting a speculative execution request via attempt interceptor would defeat the purpose of speculative execution. However, if an attempt interceptor is preferred, it would not be difficult to move the interception point.