risingwavelabs/risingwave · error · SinkError::DynamoDb

DynamoDB table {} primary key {:?} must match RisingWave pri

Error message

DynamoDB table {} primary key {:?} must match RisingWave primary key {:?}

What it means

The DynamoDB sink requires the RisingWave primary key columns to exactly match the target table's DynamoDB primary key (same count, same set of names, order-insensitive via BTreeSet). If they differ, writes would target wrong/partition keys, so validation fails with this message.

Source

Thrown at src/connector/src/sink/dynamodb.rs:441

            table_name
        )));
    }

    Ok(key_schema
        .iter()
        .map(|key_element| key_element.attribute_name().to_owned())
        .collect())
}

fn validate_pk_matches_dynamodb_key_schema(
    table_name: &str,
    rw_pk_names: &[String],
    dynamodb_keys: &[String],
) -> Result<()> {
    let rw_pk_set = rw_pk_names.iter().collect::<BTreeSet<_>>();
    let dynamodb_key_set = dynamodb_keys.iter().collect::<BTreeSet<_>>();
    if rw_pk_names.len() != dynamodb_keys.len() || rw_pk_set != dynamodb_key_set {
        return Err(SinkError::DynamoDb(anyhow!(
            "DynamoDB table {} primary key {:?} must match RisingWave primary key {:?}",
            table_name,
            dynamodb_keys,
            rw_pk_names
        )));
    }

    Ok(())
}

mod write_chunk_future {
    use std::collections::HashMap;
    use std::time::Duration;

    use anyhow::anyhow;
    use aws_sdk_dynamodb as dynamodb;
    use aws_sdk_dynamodb::client::Client;
    use dynamodb::types::{

View on GitHub (pinned to 6469eb736d)

Solutions

1. Recreate the DynamoDB table with a key schema whose attribute names exactly match the RisingWave primary-key column names.
2. Alter the RisingWave relation (or a materialized view feeding the sink) so its primary key columns match the table's key attribute names and count.
3. Recreate the sink from a materialized view with a PK matching the table keys (e.g. make the MV's PK = (pk, sk)).
4. Check for case mismatches between column names and DynamoDB key attribute names.

Example fix

// before: table key (pk, sk) but relation PK (id) -> mismatch
// after: align the MV PK with the DynamoDB key
CREATE MATERIALIZED VIEW mv AS SELECT pk, sk, payload FROM src WITH (PRIMARY KEY (pk, sk) NOT ENFORCED);
CREATE SINK s FROM mv WITH (connector='dynamodb', table='events');

aws dynamodb describe-table --table-name events --query 'Table.KeySchema[].AttributeName'  # compare against the RisingWave relation's primary key column names

When it happens

Trigger: CREATE SINK (or validation) where rw_pk_names != dynamodb_keys: e.g. RisingWave PK is (id) but the table key is (pk, sk), or column names differ in case/spelling (e.g. 'Id' vs 'id').

Common situations: Table pre-created with a composite key while the RisingWave relation has a single-column PK; key attribute names created with different casing; PK added to the RisingWave relation after the table was designed.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• table {} not found
• table {} is not active
• table {} key schema is empty
• primary key not defined for {:?} pulsar sink (please define
• Redis Sink Primary Key must be specified.

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