risingwavelabs/risingwave · critical · StreamExecutorError

Sink error: sink_id={1}, error: {0}

Error message

Sink error: sink_id={1}, error: {0}

What it means

`ErrorKind::SinkError` wraps a `SinkError` plus the `SinkId` of the failing sink, displayed as "Sink error: sink_id={1}, error: {0}". When a sink executor's write to the external sink (e.g., Kafka, JDBC, Redis) fails, the sink-specific error is converted into this variant so the log identifies exactly which sink failed.

Source

Thrown at src/stream/src/executor/error.rs:70

        ArrayError,
    ),

    #[error("Chunk operation error: {0}")]
    ExprError(
        #[from]
        #[backtrace]
        ExprError,
    ),

    // TODO: remove this after state table is fully used
    #[error("Serialize/deserialize error: {0}")]
    SerdeError(
        #[source]
        #[backtrace]
        BoxedError,
    ),

    #[error("Sink error: sink_id={1}, error: {0}")]
    SinkError(
        #[source]
        #[backtrace]
        SinkError,
        SinkId,
    ),

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

    #[error("Channel closed: {0}")]
    ChannelClosed(String),

    #[error(transparent)]

View on GitHub (pinned to 6469eb736d)

Solutions

1. Note the sink_id from the error and query `rw_catalog.rw_sinks` to identify the sink and its target.
2. Check the external system's health, credentials, and connectivity (broker reachable, topic exists, ACLs allow writes).
3. Fix data-level issues: oversize messages, schema mismatches, or constraint violations at the target.
4. After fixing the external system, the stream actor will retry; if the sink is in a permanently failed state, recreate or resume the sink.

// Pre-flight sink checks before creating it:
// - broker reachable: kafka-console-producer / redis-cli ping
// - target topic/table exists and credentials valid
// - message size within broker limits (e.g. Kafka max.request.size)

// RisingWave retries sink writes with backoff; operators should alert on
// 'Sink error: sink_id=' logs, identify the sink via
// SELECT * FROM rw_catalog.rw_sinks WHERE sink_id = '<id>';
// then fix the external system — actors resume automatically once healthy.

When it happens

Trigger: Any failure while a sink executor delivers rows to the external system — Kafka produce failures (broker down, auth, message too large), JDBC constraint violations, Redis connection errors — raised by the sink connector and wrapped as StreamExecutorError::SinkError with the sink's ID.

Common situations: External broker unavailable or credentials rotated; sink payload exceeding the broker's max message size; schema changes on the target system (new NOT NULL columns, topic deleted); network partition between RisingWave and the sink.

Related errors

• Kafka error: {0}
• connector error: {0}
• Unknown sink connector: {sink_name}
• Field '{field}' is not allowed to be altered on the fly for
• failed to parse response body

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