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 >
