@Rocky Is it a known bug ?

W20260518 09:01:59.256925 140213431002688 pipeline_driver.cpp:415] push_chunk returns not ok status Cancelled: Sort cancelled
be/src/exec/sorting/sort_column.cpp:198 sort_and_tie_helper(_cancel, &column, _sort_desc.asc_order(), inlined, _tie, cmp, _range_or_ranges, _build_tie)
be/src/exec/sorting/sort_column.cpp:521 sort_and_tie_column(cancel, column, sort_desc.get_column_desc(col_index), small_perm, tie, range, build_tie)
be/src/exec/spill/mem_table.cpp:212 sort_and_tie_columns(_runtime_state->cancelled_ref(), order_bys, _sort_desc, &_permutation)
be/src/exec/spill/mem_table.cpp:159 value_or_err_L159
be/src/exec/spill/spiller.hpp:167 captured_mem_table->done()
be/src/exec/aggregator.cpp:733 spiller->spill(state, chunk_with_st.value(), spill::ResourceMemTrackerGuard(tls_mem_tracker, state->query_ctx()->weak_from_this(), spiller->weak_from_this()))
be/src/exec/pipeline/aggregate/spillable_aggregate_blocking_sink_operator.cpp:276 _aggregator->spill_aggregate_data(state, _build_spill_task(state, should_spill_hash_table))

The error message

push_chunk returns not ok status Cancelled: Sort cancelled

is not a known standalone bug, but rather a symptom of a query being cancelled while it was trying to spill data to disk. What is happening? 1. Spilling Triggered: Your query (specifically an aggregation) exceeded the memory limit and triggered the "Spill to Disk" feature (

spillable_aggregate_blocking_sink_operator.cpp

). 2. Sorting for Spill: To spill data efficiently, StarRocks must first sort the data in memory (

mem_table.cpp

calling

sort_and_tie_columns

). 3. Cancellation Signal: While the sort was running, the pipeline driver or the query execution context received a cancellation signal. 4. Error Logged: The sorting logic checked for this cancellation and returned the status

Cancelled: Sort cancelled

. Potential Causes Since "Sort cancelled" is a standard response to a cancellation signal, you should look for the root cause of why the query was cancelled in the first place: * Query Timeout: Spilling to disk is significantly slower than in-memory processing. If your

query_timeout

(default is often 300s) is reached during the spill process, the query will be cancelled. _ _Solution*: Increase the session variable

SET query_timeout = 3600;

(or higher) for large queries. * Memory Limit (OOM): Even with spilling enabled, the sorting process itself requires memory. If the BE node hits its process memory limit (

mem_limit

) before the spill can finish, the system memory tracker may kill the query to protect the node. _ _Check*: Look at the BE

<http://be.INFO|be.INFO>

or

be.WARNING

logs around the same timestamp for "Memory limit exceeded" or "Memory tracker" messages. * Manual Cancellation: If a user or an external tool ran

KILL QUERY

, you would see this message. * Another Fragment Failed: If one part of a complex query fails (e.g., a scan node on another node), the entire query is cancelled, which would stop the sorting/spilling process on your node. Recommended Steps 1. Check Logs: Look at the BE logs (

<http://be.INFO|be.INFO>

and

be.WARNING

) for any preceding errors like

Memory limit exceeded

. 2. Increase Timeout: If the query is large, try increasing

query_timeout

. 3. Check Memory: Verify if the

query_mem_limit

is sufficient for the sorting phase of the spill. 4. Version Check: If you are on an early 3.0.x or 3.1.x version, consider upgrading to a later maintenance release (e.g., 3.1.x or 3.2.x+), as many stability improvements were made to the spilling engine. The logic causing this specific message is located in

be/src/exec/sorting/sort_column.cpp

. It is a safety check to ensure that long-running sorts don't block system shutdown or query cancellation. References • administration/management/resource_management/spill_to_disk.md • knowledge/usage/best-practice.md • using_starrocks/sorted_aggregate.md