@Rocky getting this java.sql.SQLSyntaxErrorException: Build Exec OlapScanNode fail, scan info is invalid

The error

java.sql.SQLSyntaxErrorException: Build Exec OlapScanNode fail, scan info is invalid

is an internal StarRocks error that typically occurs during the Query Planning or Coordination phase in the Front End (FE). It specifically indicates that the FE was able to generate a logical plan for your query, but when it tried to build the physical execution plan (converting an

OlapScanNode

into actual scan ranges on Back End nodes), it found that the scan information was invalid. This most commonly happens when the FE cannot find any healthy or consistent replicas (tablets) for the table you are trying to query. Common Causes and Solutions 1. Backends (BEs) are Down If the FE cannot reach the BEs hosting the data replicas, it will consider the scan info invalid. * Check: Run

SHOW BACKENDS;

in your MySQL client. * Fix: Ensure all BEs have

Alive

set to

true

. If any are down, check the

be.out

or

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

logs on those nodes to see why they crashed or stopped. 2. Unhealthy or Inconsistent Tablets If a tablet has no healthy replicas (e.g., due to disk failure, version mismatch, or failed load jobs), the FE cannot assign a BE to scan it. * Check: * Find the table's tablets:

SHOW TABLET FROM <table_name>;

* Look for tablets where

State

is not

NORMAL

or where the

Version

is significantly behind the table's

VisibleVersion

. * Run

ADMIN CHECK TABLET (<tablet_id>);

to diagnose specific tablets. * Fix: If replicas are missing, you may need to wait for StarRocks to repair them automatically, or in extreme cases, restore from backup if data is lost. 3. Metadata Inconsistency Sometimes the FE's metadata about where tablets are located becomes out of sync with the actual state of the cluster. * Fix: Usually, restarting the follower FEs or ensuring the Leader FE is healthy resolves this. Check the

fe.log

and

fe.warn.log

for any "Master not ready" or "BDBJE" related errors. 4. Concurrent Schema Change or Partition Operations If you are querying a table while it is undergoing a heavy

ALTER TABLE

(like a schema change) or while partitions are being dropped/added, the scan range might become invalid mid-planning. * Check:

SHOW ALTER TABLE COLUMN;

or

SHOW ALTER TABLE ROLLUP;

* Fix: Wait for the schema change to complete and try the query again. 5. Empty Partitions or Invalid Distribution If a table was created with an invalid distribution or all its partitions were dropped, the planner might fail to resolve scan ranges. * Check:

SHOW PARTITIONS FROM <table_name>;

to ensure the table has active partitions. Recommended Troubleshooting Steps 1. Check FE Logs: This is the most important step. Look at

fe.log

and

fe.warn.log

on your Leader FE. Search for the string

Build Exec OlapScanNode fail

. The log usually provides a more detailed stack trace or a specific reason (like "no alive replica for tablet 12345"). 2. Verify Node Health: Run

SHOW PROC '/backends';

and

SHOW PROC '/frontends';

. 3. Validate the Table: Run

CHECK TABLE <table_name>;

if available in your version, or simply try a

SELECT * FROM <table_name> LIMIT 1;

to see if it's a specific data range or the whole table that is affected. If the issue persists and all backends are alive, please provide the full stack trace from the

fe.log

for more specific guidance. References • best_practices/query_tuning/query_profile_operator_metrics.md • best_practices/query_tuning/query_planning.md • sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md • sql-reference/System_variable.md

2026-03-18 105416.399Z ERROR (lake-publish-task-783|2202) [PublishVersionDaemon.publishPartition():919] Fail to publish partition 34192 of txn 26042693: No alive backend or compute node in warehouse name: default_warehouse.

Hello! I'm Rocky, your StarRocks assistant. How can I help you today? If you have questions about StarRocks syntax, features, or need help troubleshooting a query, feel free to ask!

@Rocky 2026-03-18 105416.399Z ERROR (lake-publish-task-783|2202) [PublishVersionDaemon.publishPartition():919] Fail to publish partition 34192 of txn 26042693: No alive backend or compute node in warehouse name: default_warehouse. but in

show compute nodes

alive is true

Hello! I'm Rocky. The error

No alive backend or compute node in warehouse name: default_warehouse

during a transaction publish task (

lake-publish-task

) in StarRocks Shared-data (Lake) mode indicates that although your Compute Nodes (CNs) appear

Alive

, the Frontend (FE) cannot find a node that it considers available to process the version publishing RPC for the

default_warehouse

. Even if

Alive

is

true

, please check the following fields in the output of `SHOW COMPUTE NODES`: 1. StatusCode: This is the most common reason. For a node to be used for publishing versions, its

StatusCode

must be

OK

. * If it shows

SHUTDOWN

, the node is in the process of a graceful shutdown and will not accept new tasks. * If it shows

DISCONNECTED

, there might be a communication issue between the FE and the CN's agent service. 2. SystemDecommissioned: Ensure this is

false

. If a node is being decommissioned, the FE will stop scheduling tasks like version publishing to it. 3. WarehouseName: Confirm that the nodes you see are indeed assigned to

default_warehouse

. If they belong to a different warehouse and the table/transaction is mapped to

default_warehouse

, the FE will report this error. 4. Backend vs. Compute Node: In some configurations, the FE might be looking for a regular Backend (BE) if the cluster isn't fully configured in Lake mode, but usually, for

lake-publish-task

, it looks for nodes in the specified warehouse. Run

SHOW BACKENDS

as well to ensure there isn't a mismatch in how nodes were added. Recommended Troubleshooting Steps: * Check Node Status Detail:

sql
    SHOW COMPUTE NODES\G

Look specifically for

StatusCode

and

WarehouseName

. * Check FE Logs: The FE logs (usually

fe.log

or

fe.warn.log

) often provide more context right before this error message. Search for logs from

PublishVersionDaemon

or

LakeService

to see if there were failed RPC attempts to the CNs. * Restart the CN: If the

StatusCode

is not

OK

despite being

Alive

, try restarting the Compute Node process to refresh its state and heartbeat with the FE. * Verify Warehouse Assignment: If you are using multi-warehouse features, ensure the warehouse

default_warehouse

is active and has nodes associated with it. If the

StatusCode

is indeed

OK

and

Alive

is

true

, but you still see this error, it might be a transient state where the FE's internal warehouse cache hasn't updated yet. Usually, a brief wait or a restart of the FE leader can resolve such inconsistencies. References • faq/shared_data_faq.md • administration/management/FE_configuration.md • faq/Deploy_faq.md • data_source/datalake_faq.md

+---------------+--------------------------------------------------------------------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+--------+----------------+----------+----------+-------------------+------------+------------+------------------+----------------+------------+-------------+----------+-------------------+-----------+ | ComputeNodeId | IP | HeartbeatPort | BePort | HttpPort | BrpcPort | LastStartTime | LastHeartbeat | Alive | SystemDecommissioned | ClusterDecommissioned | ErrMsg | Version | CpuCores | MemLimit | NumRunningQueries | MemUsedPct | CpuUsedPct | DataCacheMetrics | HasStoragePath | StatusCode | StarletPort | WorkerId | WarehouseName | TabletNum | +---------------+--------------------------------------------------------------------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+--------+----------------+----------+----------+-------------------+------------+------------+------------------+----------------+------------+-------------+----------+-------------------+-----------+ | 13541097 | reporting-1-cn-0.reporting-1-cn-search.unifyapps-infra.svc.cluster.local | 9050 | 9060 | 8040 | 8060 | 2026-03-18 105240 | 2026-03-18 105830 | true | false | false | | 3.5.11-0a8fcec | 8 | 50.239GB | 0 | 0.00 % | 0.0 % | N/A | true | OK | 9070 | 40007 | default_warehouse | 0 | | 13541092 | reporting-1-cn-1.reporting-1-cn-search.unifyapps-infra.svc.cluster.local | 9050 | 9060 | 8040 | 8060 | 2026-03-18 105205 | 2026-03-18 105830 | true | false | false | | 3.5.11-0a8fcec | 8 | 50.239GB | 0 | 0.00 % | 0.0 % | N/A | true | OK | 9070 | 40006 | default_warehouse | 0 | | 4811111 | reporting-1-cn-2.reporting-1-cn-search.unifyapps-infra.svc.cluster.local | 9050 | 9060 | 8040 | 8060 | 2026-03-18 105110 | 2026-03-18 105830 | true | false | false | | 3.5.11-0a8fcec | 8 | 50.239GB | 0 | 0.00 % | 0.0 % | N/A | true | OK | 9070 | 15037 | default_warehouse | 0 | +---------------+--------------------------------------------------------------------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+--------+----------------+----------+----------+-------------------+------------+------------+------------------+----------------+------------+-------------+----------+-------------------+-----------+