Hi Joey, Thank you for that detailed context. I didn't consider the case of strict security policies.
Štefan - thank you for bumping the thread, yes, this gives me the clarity I needed. I will ensure the PR reflects this. Best, Rishabh On Wed, 1 Apr 2026 at 21:44, Štefan Miklošovič <[email protected]> wrote: > > 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
