databendlabs/databend · error

internal error: entered unreachable code

Error message

internal error: entered unreachable code

What it means

RulePushDownSortScan::apply panics with `unreachable!()` when the matched SExpr plan node is neither Sort nor TopN, or the child is neither Scan nor EvalScalar. This rewrite rule is registered only for Sort/TopN patterns, so the planner guarantees the shapes; any other shape means a rule-registration or planner bug.

Solutions

  1. Reproduce with EXPLAIN (or the failing query) and inspect the plan shape reaching the rule
  2. Verify the rule's match pattern registration matches the variants handled in apply() at rule_push_down_sort_scan.rs:69
  3. Add arms or return ErrorCode::Internal with the unexpected RelOperator debug output instead of a bare panic
  4. Run planner rule unit tests (cargo test -p databend-sql push_down_sort) after optimizer changes

Example fix

// before
let (sort_items, sort_limit) = match s_expr.plan() {
    RelOperator::Sort(sort) => (sort.items.clone(), sort.limit),
    RelOperator::TopN(top_n) => (top_n.items.clone(), Some(top_n.candidate_count())),
    _ => unreachable!(),
};
// after
let (sort_items, sort_limit) = match s_expr.plan() {
    RelOperator::Sort(sort) => (sort.items.clone(), sort.limit),
    RelOperator::TopN(top_n) => (top_n.items.clone(), Some(top_n.candidate_count())),
    other => return Err(ErrorCode::Internal(
        format!("RulePushDownSortScan got unexpected plan: {:?}", other))),
};
Defensive patterns

Strategy: validation

Validate before calling

debug_assert!(matches!(s_expr.plan(), RelOperator::Sort(_) | RelOperator::TopN(_)), "RulePushDownSortScan applied to unexpected plan");

Type guard

fn is_sort_like(op: &RelOperator) -> bool {
    matches!(op, RelOperator::Sort(_) | RelOperator::TopN(_))
}

Prevention

When it happens

Trigger: The rule's pattern/matchers in the optimizer are changed or extended (e.g. matching more RelOperator variants) while the match in apply() still only handles Sort/TopN over Scan/EvalScalar children.

Common situations: Adding a new relational operator variant or a new push-down rule pattern, rebasing optimizer changes, or a planner bug that hands a malformed SExpr to the rule.

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


AI-assisted analysis of databendlabs/databend@288d84d76e (2026-09-11). Data as JSON: /api/errors/9a4f2b35f98661ca. Report an issue: GitHub.

Appendix: source

Thrown at src/query/sql/src/planner/optimizer/optimizers/rule/filter_rules/rule_push_down_sort_scan.rs:69

                match_op!(TopN -> EvalScalar -> Scan),
            ],
        }
    }
}

impl Rule for RulePushDownSortScan {
    fn id(&self) -> RuleID {
        self.id
    }

    fn apply(&self, s_expr: &SExpr, state: &mut TransformResult) -> Result<()> {
        let (sort_items, sort_limit): (Vec<SortItem>, Option<usize>) = match s_expr.plan() {
            RelOperator::Sort(sort) => (sort.items.clone(), sort.limit),
            RelOperator::TopN(top_n) => {
                let top_n: TopN = top_n.clone();
                (top_n.items.clone(), Some(top_n.candidate_count()))
            }
            _ => unreachable!(),
        };
        let child = s_expr.child(0)?;

        let (eval_scalar, mut scan) = match child.plan() {
            RelOperator::Scan(scan) => (None, scan.clone()),
            RelOperator::EvalScalar(eval_scalar) => {
                let grand_child = child.child(0)?;
                let scan: Scan = grand_child.plan().clone().try_into()?;
                (Some(eval_scalar.clone()), scan)
            }
            _ => unreachable!(),
        };

        if scan.order_by.is_none() {
            scan.order_by = Some(sort_items);
        }

        let can_push_limit = !scan.has_secure_predicates_not_applied_by_prewhere();

View on GitHub (pinned to 288d84d76e)