risingwavelabs/risingwave · error · SchedulerError

ConnectorError

Error message

ConnectorError

What it means

This is the transparent wrapper variant of RisingWave's scheduler BatchError enum that converts any ConnectorError (raised inside a source connector) into a scheduler error. It carries no extra message — the display output is exactly the underlying connector error. It is thrown automatically via `#[from]` whenever connector code invoked from the batch scheduler pipeline fails, e.g. while listing or acquiring splits for a source.

Source

Thrown at src/frontend/src/scheduler/error.rs:58

    TaskRunningOutOfMemory,

    /// Used when receive cancel request for some reason, such as user cancel or timeout.
    #[error("Query cancelled: {0}")]
    QueryCancelled(String),

    #[error(
        "Reject query: the {0} query number reaches the limit: {1}. Use `SHOW PROCESSLIST` to check for hanging queries and cancel them if needed."
    )]
    QueryReachLimit(QueryMode, u64),

    #[error(transparent)]
    BatchError(
        #[from]
        #[backtrace]
        BatchError,
    ),

    #[error(transparent)]
    Connector(
        #[from]
        #[backtrace]
        ConnectorError,
    ),

    #[error(transparent)]
    Internal(
        #[from]
        #[backtrace]
        anyhow::Error,
    ),
}

impl From<SchedulerError> for RwError {
    fn from(s: SchedulerError) -> Self {
        ErrorCode::SchedulerError(Box::new(s)).into()
    }

View on GitHub (pinned to 6469eb736d)

Solutions

1. Read the underlying connector error message (it is transparent) and fix the root cause in the source/connector configuration.
2. Verify the source's connector properties (broker address, topic, auth, region) with `SHOW SOURCE <name>` and test external connectivity from the RisingWave node.
3. Recreate the source or table with corrected `WITH` options if the connector config is stale.
4. Check network/DNS/firewall from the RisingWave compute nodes to the external system.

Example fix

// before: failing to connect to Kafka with wrong broker
CREATE SOURCE s (...) WITH (connector='kafka', properties.broker='wrong:9092');
// after
CREATE SOURCE s (...) WITH (connector='kafka', properties.broker='kafka:9092');

-- verify the source is reachable/healthy before querying
SELECT * FROM rw_catalog.rw_sources WHERE name = 'my_source';

match scheduler_result {
    Err(e) if matches!(e, BatchError::Connector(_)) => {
        log::error!("connector failure: {e}"); // handle root connector cause
    }
    r => r?,
}

When it happens

Trigger: Any `?` conversion from `ConnectorError` into `BatchError` during query scheduling, such as when the plan fragmenter or distributed scheduler calls into the connector SDK to enumerate splits, validate a source, or read external system properties.

Common situations: Querying a table backed by Kafka/Nexmark/Datagen where the broker is unreachable, topic missing, auth credentials rejected, or where the connector SDK returns a property error. Also seen when a source's connector settings were changed after creation.

Understand the failure class

Background: "is not a compatible type" / "cannot merge" errors: when a value's type doesn't match what the library requires — this error's family across 65 libraries.

Related errors

• additional column is not supported for connector {}, accepta
• additional column type {} is not supported for connector {},
• unsupported encoding for Upsert
• Unsupported combination of format {:?} and encode {:?}
• Nats connection status is not connected, current status is {

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