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

  1. Upgrade tantivy to the version that wrote the data so the extended type code is recognized
  2. Restore the affected file from a backup or re-index the documents
  3. If producing the bytes yourself, only emit known extended codes (TOK_STR_EXT_CODE)
  4. 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

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


AI-assisted analysis of quickwit-oss/tantivy@b5d8deb80c (2026-09-05). Data as JSON: /api/errors/2768f15ccc29ee86. Report an issue: GitHub.