I'd like to announce that the backport of AutoRepair has been committed to cassandra-5.0[1]. Thanks Andy and Jaydeep for the thorough review!
This feature is gated by a JVM property "cassandra.autorepair.enable", see NEWS.txt for more information on enabling this feature[2]. System schema changes required to support this feature are only performed when the flag is enabled. As a consequence of that, it is not possible to disable the flag once enabled. This is a trade-off required to prevent schema changes during a minor upgrade for users who do not intend to enable the feature. [1] - https://github.com/apache/cassandra/commit/9500eb129bd61b2eaec78df3b9a7a5ebfca91c92 [2] - https://github.com/apache/cassandra/blob/cassandra-5.0/NEWS.txt#L79 On Fri, Mar 6, 2026 at 4:03 PM Paulo Motta <[email protected]> wrote: > Thanks Jaydeep and Andy for the review! I have addressed the review > comments and this should be ready for another look. > > I wanted to give a heads up to the community that we should be merging > this 5.0 backport soon in case there are any outstanding concerns. > > On Sun, Feb 22, 2026 at 12:59 AM Tolbert, Andy <[email protected]> > wrote: > >> I finally got around to playing around with Paulo's 5.0 backport branch >> as well and added some review feedback. I agree with Jaydeep that it looks >> great, nice work Paulo! >> >> The write up on the PR in NEWS.txt ( >> https://github.com/apache/cassandra/pull/4558/changes#diff-95c20d744db732cdbca24c3e0406c10005ecf7fe8b5719c2fdf2b8af3fcedc79) >> does a great job describing how to opt into the feature and how it >> mitigates any risk. I'm hopeful that the approach taken here makes a >> giving a +1 to a possible backport vote an easier choice for folks! >> >> Thanks! >> Andy >> >> On Sun, Feb 8, 2026 at 8:03 PM Jaydeep Chovatia < >> [email protected]> wrote: >> >>> I have looked at the PR. Overall, it looks great. Added a few comments. >>> >>> Jaydeep >>> >>> On Fri, Jan 30, 2026 at 8:20 PM Jaydeep Chovatia < >>> [email protected]> wrote: >>> >>>> I will take a look at it. Happy to see AutoRepair in 5.0. >>>> Thank you for the patch, Paulo! >>>> >>>> Jaydeep >>>> >>>> On Fri, Jan 30, 2026 at 3:27 PM Tolbert, Andy <[email protected]> >>>> wrote: >>>> >>>>> I'd be happy to take a look at reviewing this as well as I would be >>>>> excited to see Auto Repair in 5.0. Thank you for the patch, Paulo! >>>>> >>>>> Andy >>>>> >>>>> On Fri, Jan 30, 2026 at 5:13 PM Paulo Motta <[email protected]> wrote: >>>>> >>>>>> I have submitted a patch porting AutoRepair to 5.0 on >>>>>> CASSANDRA-21138[1] and tagged Jaydeep Chovatia for review. I would >>>>>> greatly >>>>>> appreciate other sets of eyes, especially those involved with the >>>>>> original >>>>>> CEP-37 effort. >>>>>> >>>>>> The feature is disabled by default and no schema changes are made >>>>>> unless a JVM flag is enabled to reduce upgrade risk to users who do not >>>>>> intend to enable this feature. >>>>>> >>>>>> Please let us know if you have any questions or concerns about having >>>>>> this merged in 5.0. >>>>>> >>>>>> [1] - https://issues.apache.org/jira/browse/CASSANDRA-21138 >>>>>> >>>>>> On Mon, Jan 12, 2026 at 8:34 PM Jaydeep Chovatia < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Sure, I am happy to review it whenever it's ready, Paulo. Please let >>>>>>> me know. >>>>>>> >>>>>>> Jaydeep >>>>>>> >>>>>>> On Mon, Jan 12, 2026 at 8:32 AM Paulo Motta <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I agree with Scott. I don't think we should backport this to 4.1 >>>>>>>> due to the compatibility issues raised plus this branch has already >>>>>>>> been >>>>>>>> stabilized for a while. >>>>>>>> >>>>>>>> I think backporting auto-repair to 5.0 would be more appropriate as >>>>>>>> it would encourage users to adopt this version and get closer to trunk, >>>>>>>> rather than encouraging users to stick to an older version. >>>>>>>> >>>>>>>> I decided to take a stab at backporting auto-repair + >>>>>>>> additional fixes to 5.0 on this preliminary PR: >>>>>>>> https://github.com/apache/cassandra/pull/4558 >>>>>>>> >>>>>>>> It's not ready for review yet since I need to gate the schema >>>>>>>> changes under a feature flag, but I think I can get it ready by the >>>>>>>> end of >>>>>>>> week. >>>>>>>> >>>>>>>> If there's no opposition against shipping this in 5.0 maybe I can >>>>>>>> create a JIRA and have Jaydeep review it ? >>>>>>>> >>>>>>>> On Mon, Jan 12, 2026 at 11:15 AM C. Scott Andreas < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> For the purpose of a quick straw poll, I’m not opposed to >>>>>>>>> backporting to 5.x, but I don’t support backporting to 4.x-series >>>>>>>>> releases >>>>>>>>> for the compatibility and upgrade complexity reasons previously >>>>>>>>> discussed. >>>>>>>>> >>>>>>>>> - Scott >>>>>>>>> >>>>>>>>> > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič < >>>>>>>>> [email protected]> wrote: >>>>>>>>> > >>>>>>>>> > Hi everybody, >>>>>>>>> > >>>>>>>>> > I want to refresh this thread after the holidays. Is there an >>>>>>>>> > agreement we reached? Is everybody on board with backporting to >>>>>>>>> 4.1+? >>>>>>>>> > How are we going to do this concretely? I guess Jaydeep would be >>>>>>>>> > involved in the backporting as he just said. I honestly do not >>>>>>>>> think >>>>>>>>> > there is anybody else better suited to make it happen and your >>>>>>>>> > willingness to do that is really appreciated. >>>>>>>>> > >>>>>>>>> > Regards >>>>>>>>> > >>>>>>>>> >> On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia >>>>>>>>> >> <[email protected]> wrote: >>>>>>>>> >> >>>>>>>>> >> FYI—regardless of the outcome, you can count on me to port >>>>>>>>> CEP-37 in whatever form the community agrees on. As mentioned >>>>>>>>> earlier, I’m >>>>>>>>> already maintaining a private 4.1.6 fork ( >>>>>>>>> https://github.com/apache/cassandra/pull/3367). >>>>>>>>> >> Thank you! >>>>>>>>> >> >>>>>>>>> >> Jaydeep >>>>>>>>> >> >>>>>>>>> >>> On Mon, Dec 22, 2025 at 7:43 AM Micah Green < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>> >>>>>>>>> >>> I'm really interested in this thread, but don't see an update >>>>>>>>> on where we landed in terms of backporting and also the amount of work >>>>>>>>> involved. I'm all for backporting to 5.x minimally! I'm planning >>>>>>>>> our 2026 >>>>>>>>> work and where this discussion goes will really help me optimally >>>>>>>>> plan, >>>>>>>>> which is why I'm asking. >>>>>>>>> >>> Thanks! >>>>>>>>> >>> >>>>>>>>> >>> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> Seems like the 4.1 branch would still require some work to >>>>>>>>> cover everything raised on this thread? Have anyone evaluated how >>>>>>>>> much work >>>>>>>>> that can be? >>>>>>>>> >>>> >>>>>>>>> >>>> I agree porting to 4.1, but not 4.0 is kind of weird. Then >>>>>>>>> probably we better have it only in 5.0? >>>>>>>>> >>>> >>>>>>>>> >>>> Do people think it makes sense to create some kind of user >>>>>>>>> survey around this work, too? Posted in @user >>>>>>>>> >>>> >>>>>>>>> >>>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>> >>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and >>>>>>>>> backporting to both would increase the risk and maintenance burden. >>>>>>>>> >>>>> >>>>>>>>> >>>>> It would but by how much? >>>>>>>>> >>>>> >>>>>>>>> >>>>> 2 things jump out to me re: risk and maintenance: >>>>>>>>> >>>>> >>>>>>>>> >>>>> Risk: We kind of need to tackle the "version straddle >>>>>>>>> w/schema table diffs is currently Bad and makes rollbacks manual and >>>>>>>>> brittle" broadly; this feature is just one more example of that >>>>>>>>> though it's >>>>>>>>> a little exacerbated by discussing doing something like this in a >>>>>>>>> patch >>>>>>>>> release. The ergonomics of the "one-way-door without a human manually >>>>>>>>> deleting columns" part holds true cross-MAJOR too. "Progress" here >>>>>>>>> seems >>>>>>>>> like it's either we handle this on a case-by-case basis w/flags to >>>>>>>>> remove >>>>>>>>> those schema entries on rollback (kinda ew), or more durably with an >>>>>>>>> elegant solution in the long term, i.e. capabilities framework, >>>>>>>>> though that >>>>>>>>> doesn't answer the "we explode when schemas don't match" bit. >>>>>>>>> >>>>> >>>>>>>>> >>>>> Maintenance: maintaining this across 4 branches is clearly >>>>>>>>> more toil than across 2. >>>>>>>>> >>>>> >>>>>>>>> >>>>> I'm personally kind of keen for us to tackle that Risk bit; >>>>>>>>> I'd like all of us to be able to more freely consider making changes >>>>>>>>> to >>>>>>>>> schema tables w/out the complexity burden we have right now and the >>>>>>>>> operator toil and risk that comes along with it. >>>>>>>>> >>>>> >>>>>>>>> >>>>> The maintenance toil bit - I have less opinions on. Kind of >>>>>>>>> depends on how many people are on 4.0/4.1 right now that we'd expect >>>>>>>>> to be >>>>>>>>> on 4.1 for another year until 7.0 hits and whether we think they'd >>>>>>>>> benefit >>>>>>>>> from the feature (and contribute to bettering it) during that year I >>>>>>>>> guess. >>>>>>>>> >>>>> >>>>>>>>> >>>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote: >>>>>>>>> >>>>> >>>>>>>>> >>>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and >>>>>>>>> backporting to both would increase the risk and maintenance burden. >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>
