risingwavelabs/risingwave · error · SinkError::Http

unexpected namespace_column type, expected varchar

Error message

unexpected namespace_column type, expected varchar

What it means

In `url_for_row`, after schema validation the namespace column should always be varchar; if a runtime datum of another type appears at the namespace index, this defensive error is thrown. It signals an internal type inconsistency (schema changed vs. sink's cached index) rather than user data being malformed.

Source

Thrown at src/connector/src/sink/turbopuffer.rs:504

    }

    fn url_for_row(&self, row: &impl Row) -> Result<String> {
        match &self.namespace {
            TurbopufferNamespace::Static(namespace) => Ok(format!(
                "{}/v2/namespaces/{}",
                self.base_url,
                namespace.as_str()
            )),
            TurbopufferNamespace::Dynamic { index } => {
                let namespace = match row.datum_at(*index) {
                    Some(ScalarRefImpl::Utf8(namespace)) => namespace,
                    None => {
                        return Err(SinkError::Http(anyhow!(
                            "Turbopuffer namespace_column cannot be null"
                        )));
                    }
                    Some(_) => {
                        return Err(SinkError::Http(anyhow!(
                            "unexpected namespace_column type, expected varchar"
                        )));
                    }
                };
                validate_namespace(namespace)?;
                Ok(format!("{}/v2/namespaces/{}", self.base_url, namespace))
            }
        }
    }

    // Turbopuffer document IDs are unsigned 64-bit integers, UUIDs, or strings up to 64 bytes.
    // RisingWave UUID IDs can be represented with varchar.
    fn id_for_row(&self, row: &impl Row) -> Result<DocumentId> {
        let datum = row.datum_at(self.pk_index).ok_or_else(|| {
            SinkError::Http(anyhow!("Turbopuffer document id column cannot be null"))
        })?;
        match datum {
            ScalarRefImpl::Int16(value) => Ok(document_id_from_i64(value as i64)),

View on GitHub (pinned to 6469eb736d)

Solutions

1. Recreate the sink so it re-validates the schema and rebuilds column indices.
2. Restore the namespace column's VARCHAR type in the upstream MV.
3. Avoid changing column order/types in the MV feeding an active sink; create a new MV and sink instead.

// Recreate the sink whenever the upstream MV schema (order/types) changes
SELECT data_type FROM rw_columns WHERE relation = 'mv_for_sink' AND name = 'ns'; // must be VARCHAR

When it happens

Trigger: Schema evolution altering the type of the namespace_column (e.g. via upstream MV recreation) while the sink still references the old column index; a bug or race between sink creation and upstream type change.

Common situations: Recreating the upstream MV with a different column order/type without recreating the sink; manually swapping a varchar namespace column for a numeric one.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

• Turbopuffer namespace_column must be varchar, got {:?}
• Turbopuffer document id column must be an integer or varchar
• Turbopuffer sink does not support column type {}
• The key encode is BYTES, but the primary key column {} has t
• ENCODE BYTES requires the column to be of type BYTEA, but go

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