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
- Inspect the wrapped storekey error to see why the value failed to encode
- Confirm the value type implements storekey::Encode and is one the engine supports (byte arrays/strings)
- Check value length constraints — very large values may exceed encoder limits
- 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
- Validate value length and type before encoding row keys
- Add round-trip tests for all value types used in sort schemas
- Avoid very large values in compound keys
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
- storekey encode ordinal
- `doc_batch` should not be empty
- Failed to serialize QueryAst
- QueryAst should be JSON serializable
- serializing PartialHit should never fail
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)