What causes "Query cancelled: {0}" in risingwavelabs/risingwave?

Inspect the reason text in the error and `SHOW PROCESSLIST` to see who/what cancelled the query.

risingwavelabs/risingwave · warning · SchedulerError

Query cancelled: {0}

Error message

Query cancelled: {0}

What it means

SchedulerError::QueryCancelled(String) is produced when a running query receives a cancel request — either explicit user cancellation (Ctrl+C / CANCEL QUERIES), a session timeout, or an internal shutdown. The message includes the reason string supplied by the cancelling party.

Source

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

pub enum SchedulerError {
    #[error("Pin snapshot error: {0} fails to get epoch {1}")]
    PinSnapshot(QueryId, u64),

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

    #[error("{0}")]
    TaskExecutionError(String),

    #[error("Task got killed because compute node running out of memory")]
    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]

View on GitHub (pinned to 6469eb736d)

Solutions

Inspect the reason text in the error and `SHOW PROCESSLIST` to see who/what cancelled the query.
If a timeout cancelled it, raise the client/statement timeout and re-run.
Re-issue the query unless it was cancelled intentionally.
Avoid killing queries accidentally: check for automated cancel jobs or idle-session timeouts in your connection pool settings.

Example fix

// raise client timeout (psql/JDBC example)
SET statement_timeout = '10min'; -- before: default that cancelled the query

Defensive patterns

Strategy: try-catch

Validate before calling

-- check for other sessions' cancel activity before long runs
SELECT * FROM SHOW PROCESSLIST;

Try / catch

// detect cancellation and re-issue or abort cleanly
catch (e) { if (e.message.startsWith('Query cancelled:')) { log(reason); optionallyRetry(); } else throw e; }

Prevention

Set client statement timeouts larger than expected query duration
Coordinate with operators before cancelling queries
Avoid long-running interactive queries on shared clusters
Configure connection pools not to kill idle in-flight statements

When it happens

Trigger: User issues `CANCEL QUERIES`/closes the connection while the query runs; a query timeout fires; the frontend or scheduler shuts down active queries; the compute task is cancelled due to upstream failure.

Common situations: Client drivers aborting on statement_timeout; operators manually cancelling long-running/hanging queries seen in `SHOW PROCESSLIST`; session termination.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

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