risingwavelabs/risingwave · error · BatchError

LogStore row sequential scan should not have input executor!

Error message

LogStore row sequential scan should not have input executor!

What it means

The `LogStoreRowSeqScanExecutorBuilder::new_boxed_executor` asserts that the LogRowSeqScan plan node receives no child executors, because a log store row sequential scan reads directly from the log store and cannot consume upstream input. Receiving an `inputs` vector that is non-empty means the distributed plan is malformed, so building the executor fails.

Source

Thrown at src/batch/executors/src/executor/log_row_seq_scan.rs:100

            metrics,
            table,
            old_epoch,
            new_epoch,
            version_id,
            ordered,
            scan_range,
        }
    }
}

pub struct LogStoreRowSeqScanExecutorBuilder {}

impl BoxedExecutorBuilder for LogStoreRowSeqScanExecutorBuilder {
    async fn new_boxed_executor(
        source: &ExecutorBuilder<'_>,
        inputs: Vec<BoxedExecutor>,
    ) -> Result<BoxedExecutor> {
        ensure!(
            inputs.is_empty(),
            "LogStore row sequential scan should not have input executor!"
        );
        let log_store_seq_scan_node = try_match_expand!(
            source.plan_node().get_node_body().unwrap(),
            NodeBody::LogRowSeqScan
        )?;

        let table_desc: &StorageTableDesc = log_store_seq_scan_node.get_table_desc()?;
        let column_ids = log_store_seq_scan_node
            .column_ids
            .iter()
            .copied()
            .map(ColumnId::from)
            .collect();

        let vnodes = match &log_store_seq_scan_node.vnode_bitmap {
            Some(vnodes) => Some(Bitmap::from(vnodes).into()),

View on GitHub (pinned to 6469eb736d)

Solutions

1. Inspect the failing batch task's plan (check meta logs / `explain`) and remove any child executor wired beneath the LogRowSeqScan node.
2. Upgrade all nodes to matching versions to rule out plan-format skew between meta and compute.
3. If it reproduces, capture the plan fragment and file a RisingWave issue — this indicates a plan-assembly bug, not user data.

// validate plan shape before dispatching the fragment
fn assert_leaf(node: &PlanNode) -> Result<()> {
    ensure!(node.children.is_empty(), "LogRowSeqScan must be a leaf node");
    Ok(())
}

When it happens

Trigger: Executing a batch plan where a `LogRowSeqScan` node has a child in the plan tree — e.g. a malformed Fragment/PlanNode protobuf where the exchange wiring attaches a child under the log-row-seq-scan node instead of under an exchange.

Common situations: Bugs or version skew in plan distribution between meta and compute nodes; corrupted or hand-modified plan fragments in tests or debugging tools; custom schedulers that mis-assemble the executor tree.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• MergeSortExchangeExecutor should not have child!
• Row sequential scan should not have input executor!
• Source should not have input executor!
• Row sequential scan should not have input executor!
• ValuesExecutor should have no child!

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