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

  1. Fix the expression syntax (balanced parens, supported operators/functions only)
  2. Test the expression standalone with the expr-lang/expr package or in the SigNoz UI preview
  3. 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

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


AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28). Data as JSON: /api/errors/179ead1247f356d2. Report an issue: GitHub.