Awesome to see the feature available in 5.0 now. Thanks a lot, Paulo, for doing the heavy lifting!
Jayeep On Wed, Apr 8, 2026 at 9:34 AM Isaac Reath <[email protected]> wrote: > This is awesome! Big thank you and congrats to everyone who worked to make > this happen! > > On Wed, Apr 8, 2026 at 12:07 PM Paulo Motta <[email protected]> wrote: > >> 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. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>
