influxdata/influxdb · error
Expected array value
Error message
Expected array value
What it means
A test panic in the `array_value` test of date_bin_wallclock.rs. The test expects the UDF to return ColumnarValue::Array when given array inputs, downcasts it to a TimestampNanosecondArray, and panics with "Expected array value" if a Scalar is returned instead.
Solutions
- Reproduce with `cargo test -p query_functions date_bin_wallclock::tests::array_value`.
- Ensure the implementation returns ColumnarValue::Array whenever any argument is an array, preserving nulls.
- If the return is intentionally scalar-folded, change the test to build the expected array from the scalar.
Example fix
// before
ColumnarValue::Array(arr) => as_timestamp_nanosecond_array(&arr).unwrap().clone(),
_ => panic!("Expected array value"),
// after
ColumnarValue::Array(arr) => as_timestamp_nanosecond_array(&arr).unwrap().clone(),
ColumnarValue::Scalar(s) => panic!("expected array value, got scalar: {:?}", s), Defensive patterns
Strategy: type-guard
Validate before calling
assert!(matches!(result, ColumnarValue::Array(_)), "array inputs must produce array output");
Type guard
fn expect_array(v: ColumnarValue) -> ArrayRef {
match v { ColumnarValue::Array(a) => a, ColumnarValue::Scalar(s) => panic!("expected array, got scalar {:?}", s) }
} Try / catch
let arr = match result {
ColumnarValue::Array(a) => a,
ColumnarValue::Scalar(s) => panic!("expected array value, got scalar {:?}", s),
}; Prevention
- Preserve null semantics when refactoring array handling in UDFs
- Never scalar-fold array inputs unless explicitly documented and tested
- Add a match arm that names the unexpected variant in panic messages
When it happens
Trigger: Calling date_bin_wallclock with array source values (including a null) and matching ColumnarValue::Array; the panic fires when the implementation collapses the result to a scalar or returns the wrong variant.
Common situations: Occurs when an optimization shortcut returns a scalar for uniform array inputs, or when array/null handling is refactored and the array path is bypassed.
Understand the failure class
Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.
Related errors
- Error computing AND
- expected Float64Array
- Expected scalar value
- Expected three arguments
- Expected timestamp data type
AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19).
Data as JSON: /api/errors/9b17227e574c97e7.
Report an issue: GitHub.
Appendix: source
Thrown at core/query_functions/src/date_bin_wallclock.rs:757
))),
ColumnarValue::Array(arr),
];
let arg_fields = arg_to_fields(&args);
let result = match udf
.invoke_with_args(ScalarFunctionArgs {
args,
arg_fields,
number_rows: 3,
return_field: return_field(DataType::Timestamp(
TimeUnit::Nanosecond,
Some(Arc::from("Europe/Paris")),
)),
config_options: default_config_options(),
})
.unwrap()
{
ColumnarValue::Array(arr) => as_timestamp_nanosecond_array(&arr).unwrap().clone(),
_ => panic!("Expected array value"),
};
assert_eq!(
result,
TimestampNanosecondArray::from(vec![
Some(MAYDAY - 2 * 60 * 60 * 1_000_000_000),
None,
Some(MAYDAY + 22 * 60 * 60 * 1_000_000_000),
])
.with_timezone("Europe/Paris")
);
}
#[test]
fn array_interval_error() {
let udf = DateBinWallclockUDF::default();
let tz = Arc::from("UTC");
let arr = Arc::new(IntervalMonthDayNanoArray::from(vec![
Some(IntervalMonthDayNano {View on GitHub (pinned to 06200ef96b)