quickwit-oss/quickwit · error

updating timestamp field is not allowed, current timestamp f

Error message

updating timestamp field is not allowed, current timestamp field `{}`, new timestamp field `{}`

What it means

The timestamp field is structural in Quickwit: it drives time partitioning, retention and pruning, so changing it would corrupt the mapping of existing splits. prepare_doc_mapping_update therefore enforces that the new mapping's timestamp_field is identical (including None) to the current one, failing with this error otherwise.

Source

Thrown at quickwit/quickwit-config/src/index_config/mod.rs:736

    // mapping UID to compare the two doc mappings, ignoring their UIDs.
    let new_doc_mapping_uid = new_doc_mapping.doc_mapping_uid;
    new_doc_mapping.doc_mapping_uid = current_doc_mapping.doc_mapping_uid;

    if new_doc_mapping == *current_doc_mapping {
        return Ok((new_doc_mapping, false));
    }
    // Restore the new doc mapping UID.
    new_doc_mapping.doc_mapping_uid = new_doc_mapping_uid;

    ensure!(
        new_doc_mapping.doc_mapping_uid != current_doc_mapping.doc_mapping_uid,
        "new doc mapping UID should differ from the current one, current UID `{}`, new UID `{}`",
        current_doc_mapping.doc_mapping_uid,
        new_doc_mapping.doc_mapping_uid,
    );
    let new_timestamp_field = new_doc_mapping.timestamp_field.as_deref();
    let current_timestamp_field = current_doc_mapping.timestamp_field.as_deref();
    ensure!(
        new_timestamp_field == current_timestamp_field,
        "updating timestamp field is not allowed, current timestamp field `{}`, new timestamp \
         field `{}`",
        current_timestamp_field.unwrap_or("none"),
        new_timestamp_field.unwrap_or("none"),
    );
    // TODO: Unsure this constraint is required, should we relax it?
    let new_tokenizers: HashSet<_> = new_doc_mapping.tokenizers.iter().collect();
    let current_tokenizers: HashSet<_> = current_doc_mapping.tokenizers.iter().collect();
    ensure!(
        new_tokenizers.is_superset(&current_tokenizers),
        "updating tokenizers is allowed only if adding new tokenizers, current tokenizers \
         `{current_tokenizers:?}`, new tokenizers `{new_tokenizers:?}`",
    );
    build_doc_mapper(&new_doc_mapping, search_settings).context("invalid doc mapping")?;
    Ok((new_doc_mapping, true))
}

View on GitHub (pinned to a39730c5cd)

Solutions

1. Keep timestamp_field unchanged in the update payload
2. If a different timestamp field is genuinely needed, create a new index (with the corrected mapping) and reindex/migrate the data
3. Remove the timestamp_field change from the submitted config and resubmit

Example fix

# before (update payload)
doc_mapping:
  timestamp_field: new_ts
# after
doc_mapping:
  timestamp_field: original_ts   # must match the current index mapping

// Rust precheck
assert_eq!(new_doc_mapping.timestamp_field, current_doc_mapping.timestamp_field, "timestamp_field is immutable");

When it happens

Trigger: update_index request whose new doc_mapping sets a different timestamp_field than the existing mapping, or adds/removes a timestamp field entirely.

Common situations: Trying to 'fix' a wrong timestamp field on a live index via update; renaming the timestamp column in the config; migrating an index from no timestamp to one (or the reverse).

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• source type cannot be changed, current type {}
• source type {} cannot be updated
• concatenate field uses an unknown field `{sub_field}`
• retention policy requires a timestamp field, but doc mapping
• new doc mapping UID should differ from the current one, curr

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