Hi Rishabh, I believe this feedback got you closer to the implementation.
Regards On Wed, Apr 1, 2026 at 12:02 AM Isaac Reath <[email protected]> wrote: > > I agree with Joey that warning is a better default than rejection. I'd hate > to be the operator that uses the latest values from cassandra_latest.yaml and > finds that now requests are being rejected that otherwise used to work, > doubly so if I wasn't having any prepared statement cache churn issues. > Having loud warnings in the logs that this is happening gives the operator > the choice to decide if this is something they are worried about or if it's > something they expect to not have any impact. > > On Tue, Mar 31, 2026 at 10:34 AM Joseph Lynch <[email protected]> wrote: >> >> I feel warning is a better default than rejection, as many places require >> prepared statements for _all_ interactions to eliminate a class of security >> bugs. I've definitely seen cases where there is a special partition that >> holds something like table metadata, userspace bloom filters, dictionaries, >> etc ... which is polled by all client nodes continuously. If you are going >> to send that statement many times (for example, when selecting a >> configuration partition), preparation still makes sense imo even if there >> are no substitutions. A warning in such a case is fine; it's just more >> context. >> >> Is the main problem here that someone is sending statements that have no >> placeholders, or that they are sending so many that other frequently used >> statements are evicted from the cache? Perhaps the guardrail should only >> trigger if the cache is nearly full (either warning _or_ rejection) which >> might make it safer to enable? >> >> -Joey >> >> On Tue, Mar 31, 2026 at 6:03 AM Štefan Miklošovič <[email protected]> >> wrote: >>> >>> Any feedback from anybody on this? >>> >>> On Thu, Mar 26, 2026 at 8:55 PM Rishabh Saraswat >>> <[email protected]> wrote: >>> > >>> > Hi everyone, >>> > >>> > I am currently doing the implementation for CASSANDRA-21139 >>> > https://issues.apache.org/jira/browse/CASSANDRA-21139 >>> > which introduces a guardrail to warn or fail against the use of >>> > misprepared statements. >>> > >>> > I am currently updating conf/cassandra_latest.yaml to include the >>> > recommended production default for this new guardrail. >>> > >>> > While the initial thought is to enable this as a warn, I wanted to >>> > open a discussion on whether it makes sense to set it to fail in >>> > cassandra_latest.yaml.I can't think of a valid production use case >>> > where misprepared statements are intentional or desirable. >>> > >>> > Is there community agreement on setting the recommended default to >>> > fail, or should we stick strictly to warn to be safe? >>> > >>> > Regards >>> > Rishabh
