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

  1. Wait until `aws dynamodb describe-table --table-name <name>` reports TableStatus ACTIVE, then retry CREATE SINK.
  2. Re-run the CREATE SINK statement once the table update/deletion operation completes.
  3. Add a wait in deployment scripts (e.g. `aws dynamodb wait table-exists` plus status check).
  4. 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

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


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