[ 
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17620175#comment-17620175
 ] 

Andres de la Peña commented on CASSANDRA-17967:
-----------------------------------------------

Indeed 4.1 is in feature freeze, and whatever we do would be for 5.0.

I think that if we are going to add custom error messages it should be done for 
all guardrails, and not only for {{allow_filtering_enabled}}. Enable flags are 
probably the easy case because they don't print the values that triggered the 
value nor any limit threshold. Other guardrails use this kind of format:
{code}
format("Cannot have more than %s tables, aborting the creation of table %s", 
threshold, what);
{code}
Maybe we should allow (or expect) those placeholders in the config property.

I don't see a lot of value in adding a property for just replacing "Querying 
with ALLOW FILTERING is not allowed" by something like "STOP using 
allow_filtering clause". Also, since we don't have fine-grained error codes for 
this kind of exceptions, customizing error messages could make it harder to 
identify the error and look for info about it. I guess that keeping the 
"Guardrail allow_filtering violated" part and customizing the details after 
that could help with identification. 

However, adding the generic "Email <[email protected]> with your cluster name 
and use-case if you would like to apply for a specific exception" at the end of 
the error message sounds quite useful to me. That customizable string could be 
the same for all user-facing errors, not only guardrails, and it could be 
defined as a single global property.

> Guardrail: allow_filtering_custom_error_message
> -----------------------------------------------
>
>                 Key: CASSANDRA-17967
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Feature/Guardrails
>            Reporter: Sarma Pydipally
>            Priority: Normal
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT 
> commands. Users get following error message :
> <stdin>:1:InvalidRequest: Error from server: code=2200 [Invalid query] 
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is 
> not allowed"
> I propose for a new parameter in conf file : something like : 
> allow_filtering_custom_error_message and allow cluster operators to configure 
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using 
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering 
> as well as give them to configure a custom error message.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to