SigNoz/signoz · error
couldn't extract log fields referenced in expr %s: %w
Error message
couldn't extract log fields referenced in expr %s: %w
What it means
For operators carrying an `expr` (e.g. add/group with expressions), the builder extracts all log-field references from the expression to build nil checks. This error means logFieldsReferencedInExpr failed before field extraction — in practice the expression could not be parsed. The pipeline is rejected at prepare time.
Source
Thrown at pkg/query-service/app/logparsingpipeline/pipelineBuilder.go:490
}
return result
}
func reverseString(s string) string {
r := []rune(s)
for i := 0; i < len(r)/2; i++ {
j := len(s) - 1 - i
r[i], r[j] = r[j], r[i]
}
return string(r)
}
// Generate expression for checking that all fields referenced in `expr` have a non nil value in log record.
// Eg: `attributes.x + len(resource.y)` will return the expression `attributes.x != nil && resource.y != nil`
func fieldsReferencedInExprNotNilCheck(expr string) (string, error) {
referencedFields, err := logFieldsReferencedInExpr(expr)
if err != nil {
return "", fmt.Errorf("couldn't extract log fields referenced in expr %s: %w", expr, err)
}
// Generating nil check for deepest fields takes care of their prefixes too.
// Eg: `attributes.test.value + len(attributes.test)` needs a nil check only for `attributes.test.value`
deepestFieldRefs := []string{}
for _, field := range referencedFields {
isPrefixOfAnotherReferencedField := slices.ContainsFunc(
referencedFields, func(e string) bool {
return len(e) > len(field) && strings.HasPrefix(e, field)
},
)
if !isPrefixOfAnotherReferencedField {
deepestFieldRefs = append(deepestFieldRefs, field)
}
}
fieldExprChecks := []string{}
for _, field := range deepestFieldRefs {View on GitHub (pinned to 5069bf80b0)
Solutions
- Fix the expression syntax (balanced parens, supported operators/functions only)
- Test the expression standalone with the expr-lang/expr package or in the SigNoz UI preview
- Simplify the expression and add complexity back incrementally to isolate the bad token
Example fix
// before
{"type":"add","field":"attributes.x","value":"expr:attributes.a +"}
// after
{"type":"add","field":"attributes.x","value":"expr:attributes.a + attributes.b"} Defensive patterns
Strategy: validation
Validate before calling
if _, err := expr.Compile(exprStr); err != nil {
return fmt.Errorf("invalid expr %q: %w", exprStr, err)
} Type guard
func isValidExpr(s string) bool { _, err := expr.Compile(s); return err == nil } Try / catch
Compile expressions client-side with expr-lang before pipeline submission; report the parser error inline next to the expression editor.
Prevention
- Use expr.Compile as a lint step in CI for pipeline-as-code
- Restrict authors to documented functions
- Preview operator output on sample logs
When it happens
Trigger: An operator with an `expr` containing invalid syntax for the embedded expr language (unbalanced parens, bad operators, unknown functions), e.g. expr "attributes.a +" or "len(resource.". fieldsReferencedInExprNotNilCheck is called from getOperators and wraps the parse failure.
Common situations: Hand-writing expressions without testing them; using SQL/ClickHouse functions not supported by the expr evaluator; version drift in supported expression functions; unescaped quotes inside strings.
Related errors
- could not create nil check for %s: %w
- could not parse expr: %w
- couldn't generate nil check for field to be removed by op %s
- couldn't generate nil check for parseFrom of time parser op
- couldn't generate layout regex for time_parser %s: %w
AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28).
Data as JSON: /api/errors/179ead1247f356d2.
Report an issue: GitHub.