SigNoz/signoz · warning

unsupported aggregate operator

Error message

unsupported aggregate operator

What it means

Returned by the log-attribute-key lookup when the aggregate operator in the request is not one of the supported cases for choosing numeric-vs-string tag filtering (only NoOp short-circuits; others fall through a switch whose default rejects). It is a request-validation error.

Source

Thrown at pkg/query-service/app/clickhouseReader/reader.go:3489

		v3.AggregateOperatorP10,
		v3.AggregateOperatorP20,
		v3.AggregateOperatorP25,
		v3.AggregateOperatorP50,
		v3.AggregateOperatorP75,
		v3.AggregateOperatorP90,
		v3.AggregateOperatorP95,
		v3.AggregateOperatorP99,
		v3.AggregateOperatorAvg,
		v3.AggregateOperatorSum,
		v3.AggregateOperatorMin,
		v3.AggregateOperatorMax:
		where = "tag_key ILIKE $1 AND (tag_data_type='int64' or tag_data_type='float64')"
		stringAllowed = false
	case
		v3.AggregateOperatorNoOp:
		return &v3.AggregateAttributeResponse{}, nil
	default:
		return nil, fmt.Errorf("unsupported aggregate operator")
	}

	query = fmt.Sprintf("SELECT DISTINCT(tag_key), tag_type, tag_data_type from %s.%s WHERE %s and tag_type != 'logfield' limit $2", r.logsDB, r.logsTagAttributeTableV2, where)
	rows, err = r.db.Query(ctx, query, fmt.Sprintf("%%%s%%", req.SearchText), req.Limit)
	if err != nil {
		r.logger.Error("Error while executing query", errorsV2.Attr(err))
		return nil, fmt.Errorf("error while executing query: %s", err.Error())
	}
	defer rows.Close()

	statements := []model.ShowCreateTableStatement{}
	query = fmt.Sprintf("SHOW CREATE TABLE %s.%s", r.logsDB, r.logsLocalTableName)
	err = r.db.Select(ctx, &statements, query)
	if err != nil {
		return nil, fmt.Errorf("error while fetching logs schema: %s", err.Error())
	}

	var tagKey string

View on GitHub (pinned to 5069bf80b0)

Solutions

1. Check which aggregate operator the request carries and use a supported one (e.g. NoOp for plain key listing)
2. Align client and query-service versions
3. Add the operator to the switch or map it to string-allowed behavior if extending SigNoz

Example fix

// before
default:
    return nil, fmt.Errorf("unsupported aggregate operator")

// after: default to string-allowed behavior for unknown ops
default:
    where = "tag_key ILIKE $1"
    stringAllowed = true

var supportedOps = map[v3.AggregateOperator]bool{v3.AggregateOperatorNoOp: true /* ... */}
if !supportedOps[req.AggregateOperator] {
    return errors.New("unsupported aggregate operator")
}

func isSupportedLogAggOp(op v3.AggregateOperator) bool {
    switch op { case v3.AggregateOperatorNoOp: return true }
    return false
}

When it happens

Trigger: Calling GetAttributeKeys (logs) with an unsupported v3.AggregateOperator in filters/aggregate source, e.g. a newly added operator constant not handled by this switch.

Common situations: Client built against a newer SigNoz API sending operators this query-service version doesn't know; hand-crafted API requests with invalid operator strings parsed to an unexpected enum value.

Related errors

• live tail is only supported for single query
• invalid data type for resource attribute: %s
• failed to validate and cast value for %s: %v
• unsupported operator: %s
• invalid aggregate operator: %w

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