risingwavelabs/risingwave · error · ExprError
field name must not be null
Error message
field name must not be null
What it means
ExprError::FieldNameNull is thrown when a field name used to access or construct a struct/object field is NULL. Field access by name requires a non-null name string; a null name is meaningless and rejected rather than producing a null result.
Solutions
- Coalesce the field name to a safe default: `get_field(obj, COALESCE(name_col, 'default_field'))`.
- Filter rows with NULL names before the field access.
- Fix upstream data so field-name columns are NOT NULL.
Example fix
// before SELECT get_field(payload, name_col) FROM t; // after SELECT CASE WHEN name_col IS NOT NULL THEN get_field(payload, name_col) ELSE NULL END FROM t;
Defensive patterns
Strategy: validation
Validate before calling
-- guard null field names before get_field SELECT CASE WHEN name_col IS NOT NULL THEN get_field(obj, name_col) ELSE NULL END FROM t;
Try / catch
// Null field name is bad input: return NULL row result instead of failing
if err.to_string().contains("field name must not be null") {
return Ok(None);
} Prevention
- Declare field-name columns NOT NULL upstream when they are used as keys.
- COALESCE nullable name columns to a default key.
- Filter NULL-name rows before object-field expressions.
When it happens
Trigger: Evaluating a `get_field`-style expression where the field-name argument is NULL (e.g. `get_field(obj, some_nullable_col)` where the column is NULL), or constructing structs with a null field name.
Common situations: Nullable name columns from upstream data used as field keys, joins that null out the key column, ETL pipelines where field names are computed dynamically.
Related errors
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/f3202550b2f25d99.
Report an issue: GitHub.
Appendix: source
Thrown at src/expr/core/src/error.rs:105
#[error("More than one row returned by {0} used as an expression")]
MaxOneRow(&'static str),
/// TODO: deprecate in favor of `Function`
#[error(transparent)]
Internal(
#[from]
#[backtrace]
anyhow::Error,
),
#[error("not a constant")]
NotConstant,
#[error("Context {0} not found")]
Context(&'static str),
#[error("field name must not be null")]
FieldNameNull,
#[error("too few arguments for format()")]
TooFewArguments,
#[error(
"null value in column \"{col_name}\" of relation \"{table_name}\" violates not-null constraint"
)]
NotNullViolation {
col_name: Box<str>,
table_name: Box<str>,
},
#[error("invalid state: {0}")]
InvalidState(String),
/// Function error message returned by UDF.
/// TODO: replace with `Function`View on GitHub (pinned to 6469eb736d)