risingwavelabs/risingwave · error · SinkError::SqlServer
column {} specified in primary_key mismatches with the downs
Error message
column {} specified in primary_key mismatches with the downstream SQL Server table {} PK What it means
For non-append-only sinks, every RisingWave primary-key column must also be a primary key column in the downstream SQL Server table. validate() raises this error when a sink column is marked as RW PK but the corresponding SQL Server column is not part of the table's PK.
Source
Thrown at src/connector/src/sink/sqlserver.rs:231
match sql_server_table_metadata.get(&normalize_sql_server_column_name(&col.name)) {
None => {
return Err(SinkError::SqlServer(anyhow!(format!(
"column {} not found in the downstream SQL Server table {}",
col.name,
self.config.full_object_path()
))));
}
Some(sql_server_col) => {
validate_data_type_compatibility(
&col.name,
&col.data_type,
&sql_server_col.data_type,
)?;
if self.is_append_only {
continue;
}
if rw_is_pk && !sql_server_col.is_pk {
return Err(SinkError::SqlServer(anyhow!(format!(
"column {} specified in primary_key mismatches with the downstream SQL Server table {} PK",
col.name,
self.config.full_object_path(),
))));
}
if !rw_is_pk && sql_server_col.is_pk {
return Err(SinkError::SqlServer(anyhow!(format!(
"column {} unspecified in primary_key mismatches with the downstream SQL Server table {} PK",
col.name,
self.config.full_object_path(),
))));
}
}
}
}
if !self.is_append_only && sql_server_pk_count != self.pk_indices.len() {
let sql_server_pk_columns = sql_server_table_metadataView on GitHub (pinned to 6469eb736d)
Solutions
- Recreate/alter the SQL Server table so its PRIMARY KEY matches the sink's primary_key columns
- Change the sink's PRIMARY KEY to match the downstream table's actual PK columns
- Make the sink append_only if upsert semantics are not needed
Example fix
// before CREATE SINK ... PRIMARY KEY (id) ...; -- SQL Server PK is (order_id) // after CREATE SINK ... PRIMARY KEY (order_id) ...; -- matches downstream PK
Defensive patterns
Strategy: validation
Validate before calling
-- list downstream PK columns and confirm they equal the sink's primary_key
SELECT c.name FROM sys.index_columns ic
JOIN sys.key_constraints kc ON ic.object_id = kc.parent_object_id AND ic.index_id = kc.unique_index_id
JOIN sys.columns c ON c.object_id = ic.object_id AND c.column_id = ic.column_id
WHERE kc.type_desc = 'PRIMARY_KEY' AND kc.parent_object_id = OBJECT_ID('target'); Try / catch
match sink.validate().await {
Err(e) if e.to_string().contains("specified in primary_key mismatches") => align_pk_with_downstream(),
other => other,
} Prevention
- Create the SQL Server table PK to exactly mirror the sink's primary_key
- Never change one side's PK without the other
- Inspect downstream PK metadata before authoring the sink
When it happens
Trigger: CREATE SINK with `primary_key(col)` where `col` exists in the SQL Server table but is not part of that table's PRIMARY KEY constraint (and the sink is not append-only).
Common situations: SQL Server table created without PK or with a different PK than the one specified in RisingWave; changing the sink's primary_key after the downstream table exists.
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
- column {} unspecified in primary_key mismatches with the dow
- primary key does not match between RisingWave sink ({}: [{}]
- DynamoDB table {} primary key {:?} must match RisingWave pri
- Primary key not defined for upsert SQL Server sink (please d
- column {} not found in the downstream SQL Server table {}
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/c3888b7ad1d095cf.
Report an issue: GitHub.