jaegertracing/jaeger · info

could not find aggregation of traceIDs

Error message

could not find aggregation of traceIDs

What it means

ErrUnableToFindTraceIDAggregation is the badger reader's sentinel for a failed trace-ID aggregation step (declared for the path where the index/aggregation pass cannot produce the trace-ID set). In the current badger implementation it is effectively a legacy/defensive declaration: the index-seek and scan code paths return raw errors instead. If seen, it means the query planner could not assemble the traceID candidate list.

Source

Thrown at internal/storage/v1/badger/spanstore/reader.go:43

var (
	// ErrServiceNameNotSet occurs when attempting to query with an empty service name
	ErrServiceNameNotSet = errors.New("service name must be set")

	// ErrStartTimeMinGreaterThanMax occurs when start time min is above start time max
	ErrStartTimeMinGreaterThanMax = errors.New("min start time is above max")

	// ErrDurationMinGreaterThanMax occurs when duration min is above duration max
	ErrDurationMinGreaterThanMax = errors.New("min duration is above max")

	// ErrMalformedRequestObject occurs when a request object is nil
	ErrMalformedRequestObject = errors.New("malformed request object")

	// ErrStartAndEndTimeNotSet occurs when start time and end time are not set
	ErrStartAndEndTimeNotSet = errors.New("start and end time must be set")

	// ErrUnableToFindTraceIDAggregation occurs when an aggregation query for TraceIDs fail.
	ErrUnableToFindTraceIDAggregation = errors.New("could not find aggregation of traceIDs")

	// ErrNotSupported during development, don't support every option - yet
	ErrNotSupported = errors.New("this query parameter is not supported yet")

	// ErrInternalConsistencyError indicates internal data consistency issue
	ErrInternalConsistencyError = errors.New("internal data consistency issue")
)

const (
	defaultNumTraces = 100
	sizeOfTraceID    = 16
	encodingTypeBits = 0x0F
)

// TraceReader reads traces from the local badger store
type TraceReader struct {
	store *badger.DB
	cache *CacheStore

View on GitHub (pinned to 806f444784)

Solutions

  1. Treat it as dead/legacy for the badger backend; handle the concrete errors from FindTraceIDs instead.
  2. If you maintain a fork where it is returned, inspect the index data/cache consistency and re-run the query with a narrower time window.
  3. Handle it defensively with errors.Is alongside ErrTraceNotFound so cross-backend error handling stays uniform.

Example fix

// before
if err != nil {
	return err // opaque failure
}
// after
if errors.Is(err, spanstore.ErrUnableToFindTraceIDAggregation) {
	log.Warn("trace ID aggregation failed; falling back to time-range scan")
}
if err != nil {
	return err
}
Defensive patterns

Strategy: try-catch

Type guard

func isAggregationFailure(err error) bool {
	return errors.Is(err, spanstore.ErrUnableToFindTraceIDAggregation)
}

Try / catch

ids, err := reader.FindTraceIDs(ctx, q)
switch {
case errors.Is(err, spanstore.ErrUnableToFindTraceIDAggregation):
	log.Warn("trace ID aggregation unavailable; retrying with narrower window")
	ids, err = reader.FindTraceIDs(ctx, narrowedWindow(q))
	if err != nil { return nil, err }
case err != nil:
	return nil, err
}

Prevention

When it happens

Trigger: Conceptually triggered from findTraceIDsFromQuery when the aggregation/index-join over trace IDs yields no usable result. In the shipped code the error variable is declared but not returned by any active call site, so encountering it by errors.Is is essentially impossible in current builds.

Common situations: Reading old Jaeger documentation or vendored code that references this error; porting code that handled it from the ES/Cassandra aggregation-based backends; confusion when mapping backend-specific errors across badger/ES/Cassandra.

Related errors


AI-assisted analysis of jaegertracing/jaeger@806f444784 (2026-09-01). Data as JSON: /api/errors/84225729ccb4d887. Report an issue: GitHub.