SigNoz/signoz · error

invalid type for service

Error message

invalid type for service

What it means

Returned by BuildClickHouseQuery when queryContext is "producer-throughput-details" and the optional variable "service_name" is not present in messagingQueue.Variables. The producer throughput detail SQL needs a service name to partition the query by producer service. Without it the builder refuses to guess and returns this error.

Source

Thrown at pkg/query-service/app/integrations/messagingQueues/kafka/translator.go:374

	var query string

	switch queryContext {
	case "producer":
		query = generateProducerSQL(start, end, topic, partition, queueType)
	case "consumer":
		consumerGroup, ok := messagingQueue.Variables["consumer_group"]
		if !ok {
			return nil, fmt.Errorf("invalid type for consumer group")
		}
		query = generateConsumerSQL(start, end, topic, partition, consumerGroup, queueType)
	case "producer-topic-throughput":
		query = generatePartitionLatencySQL(start, end, queueType)
	case "consumer_partition_latency":
		query = generateConsumerPartitionLatencySQL(start, end, topic, partition, queueType)
	case "producer-throughput-details":
		svcName, ok := messagingQueue.Variables["service_name"]
		if !ok {
			return nil, fmt.Errorf("invalid type for service")
		}
		query = generateProducerTopicLatencySQL(start, end, topic, svcName, queueType)
	case "consumer-throughput-overview":
		query = generateConsumerLatencySQL(start, end, queueType)
	case "consumer-throughput-details":
		svcName, ok := messagingQueue.Variables["service_name"]
		if !ok {
			return nil, fmt.Errorf("invalid type for service")
		}
		query = generateConsumerServiceLatencySQL(start, end, topic, svcName, queueType)
	case "producer-consumer-eval":
		query = generateProducerConsumerEvalSQL(start, end, queueType, messagingQueue.EvalTime)
	case "onboard_producers":
		query = onboardProducersSQL(start, end, queueType)
	case "onboard_consumers":
		query = onboardConsumerSQL(start, end, queueType)
	}

View on GitHub (pinned to 5069bf80b0)

Solutions

  1. Set mq.Variables["service_name"] to the producer service name before calling BuildClickHouseQuery.
  2. Verify the dashboard variable binding for producer detail widgets still maps to the key "service_name".
  3. Add a pre-call check that service_name exists for producer-throughput-details contexts and surface a descriptive validation error.
  4. Regenerate/re-save the dashboard after upgrading so variable defaults are populated.

Example fix

// before
query, err := BuildClickHouseQuery(ctx, mq, "producer-throughput-details") // Variables lacks service_name

// after
mq.Variables["service_name"] = "checkout-service"
query, err := BuildClickHouseQuery(ctx, mq, "producer-throughput-details")
Defensive patterns

Strategy: validation

Validate before calling

if queryContext == "producer-throughput-details" {
	if _, ok := mq.Variables["service_name"]; !ok {
		return fmt.Errorf("service_name variable required for producer throughput details")
	}
}

Type guard

func isProducerDetailsReady(mq *messagingqueues.MetricQueryRangeParams) bool {
	_, ok := mq.Variables["service_name"]
	return ok
}

Prevention

When it happens

Trigger: Calling BuildClickHouseQuery with queryContext == "producer-throughput-details" and a Variables map without "service_name". Reached through onboardProducers, onboardConsumers, or BuildQueryRangeParams.

Common situations: A Kafka producer details panel whose service filter variable was cleared or never set; automated dashboards provisioned from YAML that omit the service_name variable; variable key renamed between versions (e.g. service to service_name).

Understand the failure class

Background: Missing required parameter errors: what 'X is required' and 'the required X param is missing' mean, and how to fix them — this error's family across 27 libraries.

Related errors


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