risingwavelabs/risingwave · error · SinkError

no value find in sink schema, index is {:?}

Error message

no value find in sink schema, index is {:?}

What it means

When the sink has exactly one primary key column, the formatter takes the field at that pk index to build the document key. If `schema.fields().get(index)` is None — the pk index points past the end of the schema — construction fails with 'no value find in sink schema, index is {index}'.

Source

Thrown at src/connector/src/sink/elasticsearch_opensearch/elasticsearch_opensearch_formatter.rs:69

    ) -> Result<Self> {
        let key_format = if pk_indices.is_empty() {
            let name = &schema
                .fields()
                .get(0)
                .ok_or_else(|| {
                    SinkError::ElasticSearchOpenSearch(anyhow!(
                        "no value find in sink schema, index is 0"
                    ))
                })?
                .name;
            format!("{{{}}}", name)
        } else if pk_indices.len() == 1 {
            let index = *pk_indices.get(0).unwrap();
            let name = &schema
                .fields()
                .get(index)
                .ok_or_else(|| {
                    SinkError::ElasticSearchOpenSearch(anyhow!(
                        "no value find in sink schema, index is {:?}",
                        index
                    ))
                })?
                .name;
            format!("{{{}}}", name)
        } else {
            let delimiter = delimiter
                .as_ref()
                .ok_or_else(|| anyhow!("please set the separator in the with option, when there are multiple primary key values"))?
                .clone();
            let mut names = Vec::with_capacity(pk_indices.len());
            for index in &pk_indices {
                names.push(format!(
                    "{{{}}}",
                    schema
                        .fields()
                        .get(*index)

View on GitHub (pinned to 6469eb736d)

Solutions

1. Recreate the sink so pk_indices is recomputed against the current schema
2. Verify the primary key column still exists in the sink schema
3. Ensure the schema and pk_indices passed to the formatter come from the same schema version
4. If reproducible with a valid definition, file a RisingWave bug

Example fix

// before
// pk index 3 but schema has 3 fields (0..2)
ElasticSearchOpenSearchFormatter::new(schema_of_3_fields, vec![3], ...)
// after
ElasticSearchOpenSearchFormatter::new(schema_of_3_fields, vec![0], ...)

fn check_pk_in_bounds(schema: &Schema, pk_indices: &[usize]) -> Result<(), String> {
    let n = schema.fields().len();
    pk_indices.iter()
        .find(|i| **i >= n)
        .map_or(Ok(()), |i| Err(format!("pk index {} out of bounds (schema has {} fields)", i, n)))
}

When it happens

Trigger: Creating an Elasticsearch/OpenSearch sink with `pk_indices.len() == 1` whose stored index is out of bounds for the sink schema, i.e. a stale or inconsistent pk index computed against a different schema version.

Common situations: Schema changed (column dropped) after pk indices were computed; connector bug passing a pk index from the wrong schema; manual sink construction in tests with mismatched schema and pk_indices.

Related errors

• no value find in sink schema, index is 0
• please set the separator in the with option, when there are
• Primary key not defined for upsert doris sink (please define
• If you want to use upsert, please set the keysType of doris
• Can't find data

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/97c3a46bb999fb17. Report an issue: GitHub.