databendlabs/databend · error

internal error: entered unreachable code

Error message

internal error: entered unreachable code

What it means

When type-checking LAG/LEAD window functions, the planner derives `is_lag` from the function name and offset sign; the match assumes the offset is negative only for lag/lead (offset is already normalized negated earlier). A function name or offset combination outside the four listed arms triggers `unreachable!()`, i.e. internal error 1001.

Solutions

1. Express the offset positively on the right function: use `lag(x, -n)` semantics via `lead(x, n)` or `lag(x, n)`
2. Constant-fold the offset argument (use an integer literal, not an expression) so the resolver can determine its sign
3. Report as a bug with the query and version; the default arm should return an Internal ErrorCode instead of unreachable!()

Example fix

// before (window.rs:725-730)
let is_lag = match func_name {
    "lag" if offset < 0 => false,
    "lead" if offset < 0 => true,
    "lag" => true,
    "lead" => false,
    _ => unreachable!(),
};
// after
let is_lag = match func_name {
    "lag" if offset < 0 => false,
    "lead" if offset < 0 => true,
    "lag" => true,
    "lead" => false,
    _ => return Err(ErrorCode::Internal(
        format!("unexpected window func {} with offset {}", func_name, offset))),
};

-- use literal non-negative offsets on the right function
-- good: lag(x, 3) / lead(x, 3)
-- avoid: lag(x, -3) (express it as lead(x, 3))

try {
  runQuery(sql);
} catch (e) {
  if (e.code === 1001 && /lag|lead/i.test(sql)) {
    // normalize offset sign and function name, then retry
  }
}

When it happens

Trigger: Calling LAG/LEAD with a non-constant or unusual offset expression that the resolver failed to normalize to a known constant sign, so `func_name`/`offset` no longer matches any arm (e.g. other window function names routed into this resolver).

Common situations: Queries like `lag(x) over (...)` with negative offsets via `lead`, or planner regressions where a non-lag/lead name reaches resolve_lag_lead_window_function.

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

• internal error: entered unreachable code
• logic error: expected CreateTable plan
• Input plan must be Query, but it's
• Input plan must be Query, but it's
• internal error: entered unreachable code

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

Appendix: source

Thrown at src/query/sql/src/planner/semantic/type_check/window.rs:730

                _ => {
                    return Err(ErrorCode::InvalidArgument(format!(
                        "The second argument to the function {:?} must be a constant",
                        func_name
                    )));
                }
            }
        } else {
            None
        };

        let offset = offset.unwrap_or(1);

        let is_lag = match func_name {
            "lag" if offset < 0 => false,
            "lead" if offset < 0 => true,
            "lag" => true,
            "lead" => false,
            _ => unreachable!(),
        };

        let (default, return_type) = if args.len() == 3 {
            (Some(args[2].clone()), arg_types[0].clone())
        } else {
            (None, arg_types[0].wrap_nullable())
        };

        let cast_default = default.map(|d| {
            Box::new(ScalarExpr::CastExpr(CastExpr {
                span: d.span(),
                is_try: false,
                argument: Box::new(d),
                target_type: Box::new(return_type.clone()),
            }))
        });

        Ok(WindowFuncType::LagLead(LagLeadFunction {

View on GitHub (pinned to 288d84d76e)