quickwit-oss/quickwit · error

storekey encode value

Error message

storekey encode value: {}

What it means

This error fires when storekey fails to encode the value portion (a generic T: ?Sized + storekey::Encode, e.g. a byte array or prefix-column value) into the row-key buffer. The ordinal was already encoded successfully; the failure is specific to serializing the value. Bytes are optionally byte-inverted afterwards for descending sort order.

Solutions

  1. Inspect the wrapped storekey error to see why the value failed to encode
  2. Confirm the value type implements storekey::Encode and is one the engine supports (byte arrays/strings)
  3. Check value length constraints — very large values may exceed encoder limits
  4. Verify identical storekey versions in Cargo.lock across workspace crates

Example fix

// before
storekey::encode(&mut *buf, value).map_err(|e| anyhow!("storekey encode value: {}", e))?;
// after: validate first
if let Some(max) = MAX_VALUE_LEN { ensure!(value.len() <= max, "row-key value too long: {}", value.len()); }
storekey::encode(&mut *buf, value).map_err(|e| anyhow!("storekey encode value: {}", e))?;
Defensive patterns

Strategy: validation

Validate before calling

let _ = storekey::encode(&mut Vec::new(), value).map_err(|e| format!("value not encodable: {e}"))?;

Try / catch

if let Err(e) = encode_byte_array_value(&mut buf, ordinal, value, descending) {
    if e.to_string().contains("encode value") { /* record value type/len for diagnosis */ }
}

Prevention

When it happens

Trigger: Calling encode_byte_array_value or encode_prefix_col_value with a value whose storekey::Encode implementation fails — unsupported value type, encoding limit exceeded, or a writer error on the buffer.

Common situations: Encoding string/byte-array sort values into compound row keys in quickwit-parquet-engine; passing a value type not covered by the storekey encoder's registered impls.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of quickwit-oss/quickwit@a39730c5cd (2026-09-08). Data as JSON: /api/errors/c74f9b6dc17019aa. Report an issue: GitHub.

Appendix: source

Thrown at quickwit/quickwit-parquet-engine/src/sorted_series/mod.rs:294

/// columns the *value* bytes are inverted in place (NOT the ordinal
/// byte) so memcmp on the composite reverses the value's lex order
/// while ordinals stay in declared order. Caller skips this function
/// entirely for null columns — the next column's higher ordinal byte
/// then appears in this column's place, which gives nulls-last
/// ordering without a sentinel marker (matches the writer's
/// `nulls_first=false` convention).
pub(crate) fn append_prefix_col_to_key<T>(
    buf: &mut Vec<u8>,
    ordinal: u8,
    value: &T,
    descending: bool,
) -> Result<()>
where
    T: ?Sized + storekey::Encode,
{
    storekey::encode(&mut *buf, &ordinal).map_err(|e| anyhow!("storekey encode ordinal: {}", e))?;
    let value_start = buf.len();
    storekey::encode(&mut *buf, value).map_err(|e| anyhow!("storekey encode value: {}", e))?;
    if descending {
        invert_bytes(&mut buf[value_start..]);
    }
    Ok(())
}

/// Bitwise-NOT a byte slice in place, inverting the sort order for
/// descending columns in the composite key. This is the standard
/// ordered-code technique: if ascending bytes A < B, then !A > !B,
/// so memcmp on the inverted bytes gives descending order.
fn invert_bytes(bytes: &mut [u8]) {
    for byte in bytes.iter_mut() {
        *byte = !*byte;
    }
}

/// Extract a string value from a column at the given row.
///

View on GitHub (pinned to a39730c5cd)