bereng commented on code in PR #1891:
URL: https://github.com/apache/cassandra/pull/1891#discussion_r1111663766


##########
test/unit/org/apache/cassandra/db/compaction/CompactionsCQLTest.java:
##########
@@ -313,16 +314,18 @@ public void testCompactionInvalidTombstone() throws 
Throwable
     {
         
DatabaseDescriptor.setCorruptedTombstoneStrategy(Config.CorruptedTombstoneStrategy.exception);
         prepare();
+
         // write a standard tombstone with negative local deletion time (LDTs 
are not set by user and should not be negative):
-        RowUpdateBuilder rub = new 
RowUpdateBuilder(getCurrentColumnFamilyStore().metadata(), -1, 
System.currentTimeMillis() * 1000, 22).clustering(33).delete("b");
-        rub.build().apply();
-        flush();
-        compactAndValidate();
-        readAndValidate(true);
-        readAndValidate(false);
+        Assertions.assertThatThrownBy(() -> {
+            new RowUpdateBuilder(getCurrentColumnFamilyStore().metadata(),
+                                 -1,
+                                 System.currentTimeMillis() * 1000,
+                                 22).clustering(33).delete("b");
+        }).isInstanceOf(IllegalArgumentException.class)
+          .hasMessageContaining("is outside the range for an unsigned integer 
value");
     }
 
-    @Test
+    @Test(expected = RuntimeException.class)  // msg = "is outside the range 
for an unsigned integer value"

Review Comment:
   This should never happen as negative ldts just can't get in now. The 
decision in [C14092](https://issues.apache.org/jira/browse/CASSANDRA-14092) was 
that you should scrub sstables if there were any negative ldts and _not_ 
support that logic in the storage engine.
   
   So why does this test exist? digging a bit further 
[C14467](https://issues.apache.org/jira/browse/CASSANDRA-14467) seems to bring 
in some defensive logic towards negative ldts and other bad scenarios. I can 
only think this could happen on corrupted sstables which is what c14467 does: 
mark corrupted sstables. So I need to think if upon _decoding_ (bc we will 
never encode) a negative ldt outisde the valid uint range we should fail 
somehow we trigger the c14467 logic, wdyt?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to