SigNoz/signoz · warning · model.ApiError

all queries must have metric data source

Error message

all queries must have metric data source

What it means

In the anomaly-query path of queryRangeV4, every builder query that is not a formula (QueryName == Expression) must use the metrics data source. Any such plain builder query with DataSource != v3.DataSourceMetrics is rejected as bad data before execution.

Source

Thrown at ee/query-service/app/api/queryrange.go:76

			for _, fn := range query.Functions {
				if fn.Name == v3.FunctionNameAnomaly {
					anomalyQueryExists = true
					anomalyQuery = query
					break
				}
			}
		}
	}

	if anomalyQueryExists {
		// ensure all queries have metric data source, and there should be only one anomaly query
		for _, query := range queryRangeParams.CompositeQuery.BuilderQueries {
			// What is query.QueryName == query.Expression doing here?
			// In the current implementation, the way to recognize if a query is a formula is by
			// checking if the expression is the same as the query name. if the expression is different
			// then it is a formula. otherwise, it is simple builder query.
			if query.DataSource != v3.DataSourceMetrics && query.QueryName == query.Expression {
				RespondError(w, &model.ApiError{Typ: model.ErrorBadData, Err: fmt.Errorf("all queries must have metric data source")}, nil)
				return
			}
		}

		// get the threshold, and seasonality from the anomaly query
		var seasonality anomaly.Seasonality
		for _, fn := range anomalyQuery.Functions {
			if fn.Name == v3.FunctionNameAnomaly {
				seasonalityStr, ok := fn.NamedArgs["seasonality"].(string)
				if !ok {
					seasonalityStr = "daily"
				}
				if seasonalityStr == "weekly" {
					seasonality = anomaly.SeasonalityWeekly
				} else if seasonalityStr == "daily" {
					seasonality = anomaly.SeasonalityDaily
				} else {
					seasonality = anomaly.SeasonalityHourly

View on GitHub (pinned to 5069bf80b0)

Solutions

  1. Set DataSource: v3.DataSourceMetrics on all non-formula builder queries in the request
  2. Remove the offending logs/traces queries from the anomaly composite query
  3. Validate the composite query client-side before submitting

Example fix

// before
{"queryName": "A", "expression": "A", "dataSource": "logs"}
// after
{"queryName": "A", "expression": "A", "dataSource": "metrics"}
Defensive patterns

Strategy: validation

Validate before calling

for name, q := range params.CompositeQuery.BuilderQueries {
    if q.DataSource != v3.DataSourceMetrics && q.QueryName == q.Expression {
        return fmt.Errorf("query %s: anomaly queries require metrics data source", name)
    }
}

Try / catch

Not applicable — reject the request body before submission using the same rule the server enforces.

Prevention

When it happens

Trigger: POSTing a v4 query range request with an anomaly query whose builder queries include a logs or traces data-source query that is not a formula.

Common situations: Building anomaly dashboards and accidentally mixing log/traces panels, or programmatically generated composite queries defaulting to the wrong DataSource.

Related errors


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