[ASTERIXDB-3491] Failure to Reset numTupleCount When ColumnFilter Skips Megapage Causes Assembler to Enter Invalid State

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.9.9
• Fix Version/s: 0.9.9
• Component/s: STO - Storage
• Labels: triaged
• Epic Link: Columnar Format
• Assignee: Ritik Raj
• Reporter: Ritik Raj
• Created: 26/Aug/24 05:38
• Updated: 31/Aug/24 02:12
• Resolved: 30/Aug/24 17:39

Description

We have RangeFilter and ColumnFilters, where RangeFilter checks if the Megapage contains column entries within the required range. If the entries fall within this range, ColumnFilters then verifies whether the columns meet the specified push-down filters.

However, consider the following scenario:

1. The RangeFilter determines that a column has values within the requested range and sets numTupleCount to the total number of entries in the Megapage.
2. When the ColumnFilter subsequently iterates over these values, none of them satisfy the filtering conditions, leading to the decision to skip the entire Megapage.
3. Despite this, since numTupleCount is already set to a non-zero value, the assembler must skip the entries in the Megapage. This triggers the following skip() method:

   public int skip(int count) throws HyracksDataException {
       if (numberOfTuples == 0 || count == 0) {
           // Avoid advancing tupleIndex and numberOfSkips if a mega leaf node is filtered out
           return 0;
       }
       .......
        for (int i = 0; i < assemblers.length; i++) {
           assemblers[i].skip(count); // skips the entries ---- (1)
       }
       .......
   }

4. In this method, if numberOfTuples is greater than zero (as in this case), it attempts to skip entries (marked as (1) in the code). However, because no entries have been read, this results in an invalid state for the assembler, causing it to fail.