quickwit-oss/tantivy · error · io::Error
InvalidData
InvalidData
Error message
No extended field type is associated with code {ext_type_code:?} What it means
During document/schema deserialization, the EXT_CODE type code is followed by an extended type byte identifying the specific extended value type. Only TOK_STR_EXT_CODE (PreTokStr) is known; any other byte is rejected with this InvalidData error wrapped in a DeserializeError, since the encoding is undefined for unknown extended codes.
Source
Thrown at src/schema/document/de.rs:384
) -> Result<Self, DeserializeError> {
let type_code = <u8 as BinarySerializable>::deserialize(reader)?;
let value_type = match type_code {
type_codes::TEXT_CODE => ValueType::String,
type_codes::U64_CODE => ValueType::U64,
type_codes::I64_CODE => ValueType::I64,
type_codes::F64_CODE => ValueType::F64,
type_codes::BOOL_CODE => ValueType::Bool,
type_codes::DATE_CODE => ValueType::DateTime,
type_codes::HIERARCHICAL_FACET_CODE => ValueType::Facet,
type_codes::BYTES_CODE => ValueType::Bytes,
type_codes::EXT_CODE => {
let ext_type_code = <u8 as BinarySerializable>::deserialize(reader)?;
match ext_type_code {
type_codes::TOK_STR_EXT_CODE => ValueType::PreTokStr,
_ => {
return Err(DeserializeError::from(io::Error::new(
io::ErrorKind::InvalidData,
format!(
"No extended field type is associated with code {ext_type_code:?}"
),
)))
}
}
}
type_codes::IP_CODE => ValueType::IpAddr,
type_codes::NULL_CODE => ValueType::Null,
type_codes::ARRAY_CODE => ValueType::Array,
type_codes::OBJECT_CODE => ValueType::Object,
#[expect(deprecated)]
type_codes::JSON_OBJ_CODE => ValueType::JSONObject,
_ => {
return Err(DeserializeError::from(io::Error::new(
io::ErrorKind::InvalidData,
format!("No field type is associated with code {type_code:?}"),View on GitHub (pinned to b5d8deb80c)
Solutions
- Upgrade tantivy to the version that wrote the data so the extended type code is recognized
- Restore the affected file from a backup or re-index the documents
- If producing the bytes yourself, only emit known extended codes (TOK_STR_EXT_CODE)
- Hex-dump the offending byte to identify which ext code is present
Example fix
// before tantivy = "0.21" // reading data written by tantivy 0.22 with a new ext code // after tantivy = "0.22" // match (or exceed) the writer's version
Defensive patterns
Strategy: try-catch
Try / catch
match from_reader_result {
Err(e) if e.to_string().contains("No extended field type") => {
eprintln!("data written by newer/incompatible tantivy; upgrade");
}
Err(e) => return Err(e),
Ok(v) => v,
} Prevention
- Keep reader tantivy version >= writer version
- Re-export serialized documents when upgrading versions
- Only emit documented type_codes when hand-writing encodings
- Store the tantivy version alongside serialized snapshots
When it happens
Trigger: from_reader (Value deserialization) reading a stream whose EXT_CODE byte is followed by an unknown extended type code: files written by a newer tantivy version introducing new ext types, corrupted byte streams, or hand-crafted serialization in tests/tools.
Common situations: Forward-compatibility break: an index or document snapshot written by a newer tantivy that supports extra extended field types, read by an older version; bit rot in stored documents containing pre-tokenized strings.
Related errors
- No field type is associated with code {type_code:?}
- Invalid value type id: {num}
- InvalidData
- Corrupted data. Invalid VInt 32
- Field already exists in schema {}
AI-assisted analysis of quickwit-oss/tantivy@b5d8deb80c (2026-09-05).
Data as JSON: /api/errors/2768f15ccc29ee86.
Report an issue: GitHub.