Hi everyone, I would like to discuss an idea to make cassandra guardrails more visible to clients/applications.
Currently, when a guardrail is violated a warning in form of human readable string is sent back to the driver. There is not standard way for applications to inspect guardrail violations programmatically without relying on error messages. Would it be useful to expose guardrail information to clients in a structured manner? I see potential benefits: 1) Observability: Drivers could potentially expose guardrail-specific metrics, allowing applications to monitor warning and failure rates and trigger alerts when violations become frequent. 2) Visibility: applications can see relevant guardrail information, such as which guardrails are enabled and their configured thresholds, where appropriate. 3) Applications could distinguish guardrail violations from other request failures. One possible approach would be to expose structured guardrail metadata through the native protocol. Drivers could provide generic support for exposing this information to applications, without needing to maintain their own knowledge of individual guardrails. Backward compatibility can be maintained by knowing if driver supports this support during handshake itself(one possible approach). I'm raising this as an exploratory idea rather than proposing a specific implementation. I'd be interested in thoughts on a few questions: Q1) Is there a meaningful use case for applications to inspect server guardrail configuration(like observability I mentioned above)? Q2) Would correlating request failures and warnings with specific guardrails enable useful driver metrics or application-level monitoring? Q3) If this functionality is desirable, what would be the simplest way to expose it without introducing unnecessary complexity across the driver ecosystem?
