My own .02: this sounds useful. I wouldn't extend the native protocol with that though but instead present a REST-based endpoint through the sidecar or a node to allow external clients to query this data. If we extend the native protocol with that information that means needing to potentially extend 7? 8? or more drivers to have support for this native protocol spec extension vs. just pulling it down from a simple structured REST API that's trivial to write against.
Q1: I think so. Applications / agents being able to self-discover what constraints the cluster is pushing back on them can inform better design to stay within the bounds of those guardrails during modeling and QA. Q2: Hm. Maybe - this would argue for it being integrated w/the drivers and native protocol route. Question is: what does this correlation enable? What feature do you have in mind for Q2 in what it exposes to users / applications? Dynamic behavior changes, backoff, etc based on guardrail-based failures or pushback? Q3: Ah hah. Yeah, the complexity question and the drivers; this is why I land on the "let's go industry standard and start moving in that direction". Drivers would definitely still need "smarts" if we want them to back off or change routing or decision making based on these metrics, but ultimately I think most guardrails are more in the realm of constraining _applications_ rather than constraining _drivers_, meaning the driver would just be a middleman for messages between the server and the decision-making code that will actually act on that data. From that frame, I'd say "Go REST and have applications be able to read it". That said, I'm not intimately familiar with the guts of the drivers and what smarts or decision-making there may be better served by native protocol - I'll defer to Brett, Jane, and others on that piece of things. Sounds interesting though - the more we can get guardrails exposed, configurable, visible, and "integratable" with applications the more impact they'll have. Good call. On Fri, Oct 16, 2026, at 3:50 PM, Rishabh Saraswat wrote: > 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? >
