quickwit-oss/quickwit · error

`index_uri` cannot be updated, current value {}, new expecte

Error message

`index_uri` cannot be updated, current value {}, new expected value {}

What it means

`load_index_config_update` also forbids changing an index's `index_uri` (the object storage location where splits are written). After parsing the updated config, it compares the new `index_uri` with the current one and fails with this message if they differ, because relocating an index's data directory via a config update is not supported.

Source

Thrown at quickwit/quickwit-config/src/index_config/serialize.rs:86

/// default values will be used, not those of the current index config.
pub fn load_index_config_update(
    config_format: ConfigFormat,
    index_config_bytes: &[u8],
    default_index_root_uri: &Uri,
    current_index_config: &IndexConfig,
) -> anyhow::Result<IndexConfig> {
    let mut new_index_config = load_index_config_from_user_config(
        config_format,
        index_config_bytes,
        default_index_root_uri,
    )?;
    ensure!(
        current_index_config.index_id == new_index_config.index_id,
        "`index_id` in config file {} does not match updated `index_id` {}",
        current_index_config.index_id,
        new_index_config.index_id
    );
    ensure!(
        current_index_config.index_uri == new_index_config.index_uri,
        "`index_uri` cannot be updated, current value {}, new expected value {}",
        current_index_config.index_uri,
        new_index_config.index_uri
    );
    let (updated_doc_mapping, _mutation_occurred) = prepare_doc_mapping_update(
        new_index_config.doc_mapping,
        &current_index_config.doc_mapping,
        &new_index_config.search_settings,
    )?;
    new_index_config.doc_mapping = updated_doc_mapping;

    Ok(new_index_config)
}

impl IndexConfigForSerialization {
    fn index_uri_or_fallback_to_default(
        &self,

View on GitHub (pinned to a39730c5cd)

Solutions

  1. Revert `index_uri` in the config file to the current value
  2. If migration is truly needed, create a new index at the new URI and re-index or copy data there
  3. Check environment-specific config overlays (staging vs prod) for a wrong `index_uri`

Example fix

// before
index_uri: s3://new-bucket/indexes/my-index
// after
index_uri: s3://original-bucket/indexes/my-index
Defensive patterns

Strategy: validation

Validate before calling

fn ensure_index_uri_unchanged(current_uri: &str, new_config: &str) -> anyhow::Result<()> {
    let new_uri = extract_index_uri(new_config)?;
    if new_uri != current_uri {
        anyhow::bail!(
            "config index_uri `{new_uri}` differs from current `{current_uri}`; \
             index_uri cannot be updated"
        );
    }
    Ok(())
}

Try / catch

match load_index_config_update(...) {
    Err(e) if e.to_string().contains("`index_uri` cannot be updated") => {
        eprintln!("Revert index_uri in the config to the existing value.");
    }
    other => other?,
}

Prevention

When it happens

Trigger: Calling `update_index` / `load_index_config_update` with a config file whose `index_uri` differs from the current index config's `index_uri`.

Common situations: Moving an index to a new bucket or path by editing `index_uri`; switching between local and object-storage URIs; copying a config from a differently-hosted environment.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors


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