Skip to content
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

Add query interceptors #1810

Closed
wants to merge 1 commit into from
Closed

Conversation

BenEddy
Copy link

@BenEddy BenEddy commented Sep 3, 2024

This PR introduces QueryInterceptor and BatchInterceptor interfaces for intercepting queries immediately before execution, which allows clients to inject logic that should apply to all queries. My personal use case is context 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.

@hardikmadhu
Copy link

Hi @BenEddy ! Thanks for the work here! I have also been looking to do something similar to log some context. I have a couple of questions, but I'm a total golang noob, so ignore if some of these comments don't make sense.

  1. As you elaborate in your description, if the idea is to log some context, configuring driver side rate limiter etc, wouldn't it be a better idea to add the intercept on Attempts? If you're in a real pickle, where you're actually trying to debug something, host timeouts, network issues, server load etc, having an intercept in the attempt would be invaluable.
  2. Since the query and batch intercept are almost identical, except the type of query, wouldn't it be possible to define an interface, that could take either query or batch as an argument and we'd be able to decide what intercept to execute after assessing the type?

@BenEddy
Copy link
Author

BenEddy commented Sep 12, 2024

@hardikmadhu After more consideration, I think you're right that intercepting at a lower level is probably a better way to go. Opened #1820 and will close this out for now.

@BenEddy BenEddy closed this Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants