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 >> >
