[CASSANDRA-16223] Reading dense table yields invalid results in case of row scan queries

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 3.0.23, 3.11.9
• Component/s: Consistency/Coordination
• Bug Category: Correctness - Consistency
• Severity: Low
• Complexity: Low Hanging Fruit
• Discovered By: Unit Test
• Platform: All
• Since Version: 3.0.0

Source Control Link

https://github.com/apache/cassandra/commit/f106ef0697e172492b0343462c593edb703f2ac8, https://github.com/apache/cassandra/commit/833ba83c155871247092d6783d026c27582cde7b

Test and Documentation Plan

Run unit tests, especially ThriftIntegrationTest

• Assignee: Jacek Lewandowski
• Reporter: Jacek Lewandowski

Authors

Jacek Lewandowski

Reviewers

Sylvain Lebresne

• Created: 22/Oct/20 20:34
• Updated: 19/Nov/21 06:51
• Resolved: 02/Nov/20 10:43

Description

ThriftIntegrationTest is broken in the way that it does not actually test reads before and after flushing, because it does not do flush at all (see https://github.com/apache/cassandra/blob/cassandra-3.11/test/unit/org/apache/cassandra/cql3/validation/ThriftIntegrationTest.java#L939). After fixing that method so that it really flushes memtables to disk, we can see inconsistency in reads from dense table - the results returned from memtable differs from the results returned from sstable (the later are wrong, cell values are skipped unexpectedly).

java.lang.AssertionError: Invalid value for row 0 column 0 (value of type ascii), expected <value1> but got <>

In principle this problems is about skipping column values when doing row scan queries with explicitly selected columns (not wildcard), when the columns belong to a super column. This happens only when reading from sstables, it does not happen when reading from memtables.

Issue Links

• relates to: CASSANDRA-15962 Digest for some queries is different depending whether the data are retrieved from sstable or memtable