risingwavelabs/risingwave · warning · SchedulerError

Reject query: the {0} query number reaches the limit: {1}. U

Error message

Reject query: the {0} query number reaches the limit: {1}. Use `SHOW PROCESSLIST` to check for hanging queries and cancel them if needed.

What it means

SchedulerError::QueryReachLimit is raised by the frontend admission control when the number of concurrent (or queued) queries of a given QueryMode (local/distributed) reaches the configured limit. The query is rejected before execution, and the message suggests using `SHOW PROCESSLIST` to find hanging queries.

Source

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

    #[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]
        ConnectorError,
    ),

View on GitHub (pinned to 6469eb736d)

Solutions

Run `SHOW PROCESSLIST` and cancel hanging/stale queries with `CANCEL QUERIES <query_id>` to free slots.
Wait for existing queries to finish, or add client-side throttling/connection pooling limits.
Raise the concurrency limit: `SET query_mode_max_concurrent_queries = <n>` (per mode via corresponding session config).
Investigate why queries hang — often a slow compute node or an unbounded query blocking slots.

Example fix

-- before: rejected at default limit
-- after
SET query_mode_max_concurrent_queries = 32;
SELECT ...;

Defensive patterns

Strategy: validation

Validate before calling

-- check current concurrency before submitting
SHOW PROCESSLIST; -- compare count against SHOW PARAMETERS LIKE 'query_mode_max_concurrent_queries';

Try / catch

// catch rejection, wait, retry
catch (e) { if (e.message.includes('Reject query')) { await sleep(jitter); retry(); } else throw e; }

Prevention

Run SHOW PROCESSLIST regularly and cancel hung queries
Throttle clients via connection pooling
Raise query_mode_max_concurrent_queries when load justifies it
Investigate queries that hang and hold admission slots

When it happens

Trigger: Submitting a new query while the count of running queries for the mode reaches the session-level limit configured via `SET QUERY_MODE_MAX_CONCURRENT_QUERIES`-style session config (default 12 per mode).

Common situations: Many concurrent dashboards/jobs hammering RisingWave; a hung query leaking and holding a slot until the limit is exhausted; load tests exceeding configured concurrency.

Related errors

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