risingwavelabs/risingwave · error · SinkError::DynamoDb
table {} is not active
Error message
table {} is not active What it means
After DescribeTable succeeds during sink validation, the connector checks that the table's status is ACTIVE. DynamoDB tables that are CREATING, UPDATING, or DELETING are not ready to receive writes, so validation fails with this message.
Source
Thrown at src/connector/src/sink/dynamodb.rs:179
let client = (self.config.build_client().await)
.context("validate DynamoDB sink error")
.map_err(SinkError::DynamoDb)?;
let table_name = &self.config.table;
let output = client
.describe_table()
.table_name(table_name)
.send()
.await
.map_err(|e| anyhow!(e))?;
let Some(table) = output.table else {
return Err(SinkError::DynamoDb(anyhow!(
"table {} not found",
table_name
)));
};
if !matches!(table.table_status(), Some(TableStatus::Active)) {
return Err(SinkError::DynamoDb(anyhow!(
"table {} is not active",
table_name
)));
}
let rw_pk_names = rw_pk_names(&self.schema, &self.pk_indices)?;
let dynamodb_keys = dynamodb_key_schema_names(table_name, table.key_schema())?;
validate_pk_matches_dynamodb_key_schema(table_name, &rw_pk_names, &dynamodb_keys)?;
Ok(())
}
async fn new_log_sinker(&self, _writer_param: SinkWriterParam) -> Result<Self::LogSinker> {
Ok(
DynamoDbSinkWriter::new(self.config.clone(), self.schema.clone())
.await?
.into_log_sinker(self.config.max_future_send_nums),
)
}View on GitHub (pinned to 6469eb736d)
Solutions
- Wait until `aws dynamodb describe-table --table-name <name>` reports TableStatus ACTIVE, then retry CREATE SINK.
- Re-run the CREATE SINK statement once the table update/deletion operation completes.
- Add a wait in deployment scripts (e.g. `aws dynamodb wait table-exists` plus status check).
- Verify no other process is updating or deleting the table concurrently.
Example fix
// before: create-table then immediately CREATE SINK (table still CREATING) // after: aws dynamodb wait table-exists --table-name events aws dynamodb describe-table --table-name events # confirm ACTIVE CREATE SINK s FROM mv WITH (connector='dynamodb', table='events');
Defensive patterns
Strategy: retry
Validate before calling
aws dynamodb describe-table --table-name events --query 'Table.TableStatus' # expect "ACTIVE"
Try / catch
// retry CREATE SINK after the table reaches ACTIVE status, with backoff
for (let attempt = 0; attempt < 5; attempt++) {
if (await tableStatusIs('events', 'ACTIVE')) { await createSink(); break; }
await sleep(backoff(attempt));
} Prevention
- Use `aws dynamodb wait table-exists` before creating the sink.
- Sequence IaC so table mutations finish before sink (re)creation.
- Check TableStatus in pre-deploy health checks.
When it happens
Trigger: CREATE SINK issued while the target DynamoDB table is still being created (status CREATING) or is mid-update/deletion; also occurs right after running create-table and immediately creating the sink.
Common situations: Infrastructure-as-code scripts that create the table and the RisingWave sink back-to-back without waiting for ACTIVE status; table undergoing GSI changes; table being deleted concurrently.
Understand the failure class
Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.
Related errors
- table {} not found
- table {} key schema is empty
- DynamoDB table {} primary key {:?} must match RisingWave pri
- failed to write items to DynamoDB sink
- No allow_alter_on_fly fields registered for sink: {sink_name
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/0a3823e3f4199332.
Report an issue: GitHub.