What causes "Can't find message proto {}" in risingwavelabs/risingwave?

Set the sink's `table` property to a plain valid protobuf identifier (letters, digits, underscore; no dots or dashes); set project/dataset via their own properties.

risingwavelabs/risingwave · error · SinkError::BigQuery

Can't find message proto {}

Error message

Can't find message proto {}

What it means

When creating a BigQuery sink writer, RisingWave builds a protobuf descriptor pool from the sink schema with a message named after the sink's `table` config property, then looks up that message descriptor. This error means the pool was built but does not contain a message with the configured table name, i.e. the generated proto descriptor name does not match the table name string used for lookup.

Source

Thrown at src/connector/src/sink/big_query.rs:689

                .map(|f| (f.name.as_str(), &f.data_type)),
            config.common.table.clone(),
        )?;

        if !is_append_only {
            let field = FieldDescriptorProto {
                name: Some(CHANGE_TYPE.to_owned()),
                number: Some((schema.len() + 1) as i32),
                r#type: Some(field_descriptor_proto::Type::String.into()),
                ..Default::default()
            };
            descriptor_proto.field.push(field);
        }

        let descriptor_pool = build_protobuf_descriptor_pool(&descriptor_proto)?;
        let message_descriptor = descriptor_pool
            .get_message_by_name(&config.common.table)
            .ok_or_else(|| {
                SinkError::BigQuery(anyhow::anyhow!(
                    "Can't find message proto {}",
                    config.common.table
                ))
            })?;
        let proto_field = if !is_append_only {
            let proto_field = message_descriptor
                .get_field_by_name(CHANGE_TYPE)
                .ok_or_else(|| {
                    SinkError::BigQuery(anyhow::anyhow!("Can't find {}", CHANGE_TYPE))
                })?;
            Some(proto_field)
        } else {
            None
        };
        let row_encoder = ProtoEncoder::new(
            schema.clone(),
            None,
            message_descriptor.clone(),

View on GitHub (pinned to 6469eb736d)

Solutions

Set the sink's `table` property to a plain valid protobuf identifier (letters, digits, underscore; no dots or dashes); set project/dataset via their own properties.
Check build_protobuf_schema to confirm the message name it generates exactly matches config.common.table.
Verify build_protobuf_descriptor_pool registers the file under the expected package/name used by get_message_by_name.
Log the descriptor pool's message names before lookup to see what name actually exists.

Example fix

// before
'bigquery.table' = 'my-project.my-dataset.my-table'
// after
'bigquery.table' = 'my_table'  // project/dataset set via their own properties

Defensive patterns

Strategy: validation

Validate before calling

-- `table` must be a valid protobuf identifier; check in config:
-- reject if it contains '.', '-', or starts with a digit.
SELECT table_name FROM `<project>.<dataset>.INFORMATION_SCHEMA.TABLES`
WHERE table_name = '<table>';  -- confirms the table exists

Try / catch

match sink_creation {
    Err(SinkError::BigQuery(e)) if e.to_string().contains("Can't find message proto") => {
        // fix the `table` config value to a valid protobuf identifier and retry
    }
    other => other?,
}

Prevention

Keep the `table` property a plain identifier: no dots, dashes, or special characters.
Set project and dataset through their dedicated config fields, never inside `table`.
Test CREATE SINK in a dev environment to catch name mismatches early.
After config changes, verify the error's interpolated table name matches what you expect.

When it happens

Trigger: Calling BigQuerySinkWriter::new where build_protobuf_descriptor_pool succeeded but config.common.table does not equal the message name actually inserted into the pool - e.g. the table name contains dots, dashes, or case that was transformed when constructing the FileDescriptorProto.

Common situations: Table property containing a dot (e.g. 'project.dataset.table' given as table), table names with invalid protobuf identifier characters, or mismatched naming between descriptor construction and lookup after a config change.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

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