I wouldn't be surprised if we don't have logic in place to handle that disjoint (DDL for disabled .yaml property) at least in the case of CDC. It's been the better part of a decade since that first impl but I don't have any recollection of that logic being in there.
Let me take a quick look at the code and I'll get back to you; might need a JIRA. On Fri, Sep 20, 2024, at 11:50 AM, Štefan Miklošovič wrote: > Thank you for reporting this. I may check next week more closely and let you > know. > > On Fri, Sep 20, 2024 at 5:43 PM Bowen Song via user > <user@cassandra.apache.org> wrote: >> Hi all, >> >> I suspect that I've ran into a bug (or two). >> >> On Cassandra 4.1.1, when `cdc_enabled` in the cassandra.yaml file is set >> to `false` on at least one node in the cluster, and then the `ALTER >> TABLE ... WITH cdc=...` statement was run against that node, the cluster >> will end up in the schema disagreement state. At this stage, a rolling >> restart will bring the schema back in sync, but the changes made to the >> `cdc` table property will be lost. >> >> On Cassandra 4.1.6, the same procedure doesn't cause visible schema >> disagreement in the `nodetool describecluster` command's output, but the >> `ALTER TABLE` statement only has cosmetic effect on the node it is run. >> The node with `cdc_enabled` set to `false` will show the `cdc` table >> property has changed, but this does not affect its behaviour in any way. >> At the same time, other nodes do not see that table property change at >> all. This is perhaps even worse than on 4.1.1, because the alter table >> statement is silently failing. >> >> A shell script for reproducing the above described behaviours, and the >> output on both 4.1.1 and 4.1.6 are attached. >> >> (as a good security practice, please always read and understand the full >> script you downloaded from untrusted sources before attempting to run it) >> >> So, are these bugs? Or is this some kind of behaviour that's documented >> but I failed to find that documentation for? >> >> Cheers, >> Bowen