cube-js/cube · critical

Unhandled encoding ordinal {}

Error message

Unhandled encoding ordinal {}

What it means

This panic comes from CubeStore's HLL (HyperLogLog) deserialization in cubehll. When reading a serialized HLL instance, the stored encoding ordinal byte does not match any known encoding (e.g. dense or sparse variants the code knows how to decode), so read fails fast with a panic rather than returning garbage results. It indicates corrupt, truncated, or version-incompatible HLL sketch data.

Source

Thrown at rust/cubestore/cubehll/src/instance.rs:261

                if data.len() != expected_len as usize {
                    return Err(HllError::new(format!(
                        "Expected {} data bytes for encoding FULL with log2m={}, got {}",
                        expected_len,
                        log_num_buckets,
                        data.len()
                    )));
                }
                let mut values = Vec::with_capacity(num_buckets as usize);
                let mut cursor = BitCursor::new(data);
                for _ in 0..num_buckets {
                    values.push(cursor.read_bits(reg_width as usize).unwrap() as u8)
                }
                Ok(HllInstance::Dense(DenseHll::new_from_entries(
                    log_num_buckets,
                    values,
                )?))
            }
            enc => panic!("Unhandled encoding ordinal {}", enc),
        }
    }

    pub fn read_snowflake(s: &str) -> Result<HllInstance> {
        #[derive(Deserialize)]
        struct SerializedHll {
            precision: u8,
            version: u8,
            sparse: Option<SparseEntries>,
            dense: Option<Vec<u8>>,
        }
        #[derive(Deserialize)]
        #[allow(non_snake_case)]
        struct SparseEntries {
            indices: Vec<u32>,
            maxLzCounts: Vec<u8>,
        }

View on GitHub (pinned to 7d981676b3)

Solutions

1. Verify the CubeStore version that wrote the data matches the version reading it; align versions (upgrade the reader or re-generate data with the current version).
2. Delete/rebuild the affected HLL sketch data (drop and re-run the pre-aggregation or query so the sketch is recomputed).
3. If data is suspect, restore CubeStore data files from a backup or re-ingest the source partition.
4. If you control the code, extend the match in instance.rs to handle the new encoding instead of panicking, or return a proper CubeError.

Example fix

// before
enc => panic!("Unhandled encoding ordinal {}", enc),
// after
enc => return Err(CubeError::internal(format!("Unhandled HLL encoding ordinal {}; data may be from an incompatible CubeStore version", enc))),

// Check encoding ordinal before deserializing an HLL blob
fn is_known_hll_encoding(bytes: &[u8]) -> bool {
    !bytes.is_empty() && matches!(bytes[0], 0 | 1) // ordinals handled by this build
}

fn looks_like_hll_blob(bytes: &[u8]) -> bool {
    !bytes.is_empty() && bytes.len() > 1 && bytes[0] <= 1
}

When it happens

Trigger: Calling HllInstance::read (or read_snowflake-adjacent deserialization paths) on bytes whose first/encoding byte is an unrecognized ordinal — typically data written by a newer cubehll version, manually edited/corrupted storage, or bytes not produced by HllInstance serialization at all.

Common situations: Upgrading/downgrading CubeStore so on-disk HLL sketches (e.g. approximate distinct-count pre-aggregations) were written with a different encoding ordinal; a corrupted CubeStore metadata/partition file; feeding arbitrary bytes into the deserializer.

Related errors

• Older version of orchestrator is being used with newer versi
• Field payload is empty, incorrect response for ${method} met
• Request of {} bytes exceeds the maximum message size of {} b
• CacheStore cannot be used on the worker node! cache_all was
• CacheStore cannot be used on the worker node! cache_set was

AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/5f10d0ab71970c8e. Report an issue: GitHub.