There was a time probably a 17 years ago where I used specially crafted timestamps to implement a read-free leaderboard concept for a high throughput video game system that didn’t care about the lossy nature of score conflicts, so I’m sure some people do horrible things with client supplied timestamps to trick cell resolution (because I was one of those people), but even I didn’t think this went to the markedForDeleteAt value on deletions.
I’d strongly suspect the people seeing this have corruption from missing checksums and latent bitflips. > On Oct 6, 2026, at 8:40 PM, Paulo Motta <[email protected]> wrote: > > > Hi, > > According to this AI-assisted analysis on CASSANDRA-21729[1], negative > deletion timestamps which are accepted by CQL will cause > CorruptSSTableException on 5.0 but not on 4.0. This is easily reproducible on > 5.0 with: > INSERT INTO ks.t (k, v) VALUES (1, 1) USING TIMESTAMP 100; > DELETE FROM ks.t USING TIMESTAMP -5 WHERE k = 1; > SELECT * FROM ks.t WHERE k = 1; -- after flush, throws > CorruptSSTableException (works fine in 4.0) > > I can't think of a legitimate reason why someone would use negative > timestamps other than a bug/corruption, but it turns out that some 4.X users > are reporting seeing this error after upgrading in both BTI and BIG formats. > My guess is this surfacing some old corruption not detected by 4.X. > > Can someone with more expertise in the area confirm the bug is legitimate ? > > The fix might involve an sstable format change, or stop supporting negative > timestamps. I would personally prefer to stop supporting negative timestamps, > and a flag to disable this for obscure use cases. > > Let me know what do you think, > > Paulo > > [1] - > https://issues.apache.org/jira/browse/CASSANDRA-21729?focusedCommentId=18124156&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18124156
