jaegertracing/jaeger · info

this storage backend does not compute trace summaries native

Error message

this storage backend does not compute trace summaries natively: %w

What it means

UnsupportedTraceSummaries is a drop-in embed for a Reader that does not implement FindTraceSummaries natively. Its iterator yields a single (nil, error) that wraps errors.ErrUnsupported with this message, telling the caller this storage backend cannot compute trace summaries itself and that the caller should fall back to FindTraces plus client-side aggregation. It is an intentional capability signal, not a bug.

Source

Thrown at internal/storage/v2/api/tracestore/summary.go:58

	ErrorSpanCount int
	// OrphanSpanCount is the number of spans that have a parent span ID that
	// is not present in this trace (i.e. the trace is incomplete).
	OrphanSpanCount int
	// Services contains one entry per distinct service name observed across all spans,
	// including the root span's service. Entries are sorted by service name.
	Services []ServiceSummary
}

// UnsupportedTraceSummaries provides a Reader.FindTraceSummaries implementation
// for backends that cannot compute trace summaries natively. It yields
// errors.ErrUnsupported as its first (and only) error, which signals the caller
// to fall back to FindTraces + client-side aggregation. Embed it in a Reader to
// opt into that behavior without writing the method by hand.
type UnsupportedTraceSummaries struct{}

func (UnsupportedTraceSummaries) FindTraceSummaries(context.Context, TraceQueryParams) iter.Seq2[[]TraceSummary, error] {
	return func(yield func([]TraceSummary, error) bool) {
		yield(nil, fmt.Errorf("this storage backend does not compute trace summaries natively: %w", errors.ErrUnsupported))
	}
}

View on GitHub (pinned to 806f444784)

Solutions

  1. Implement FindTraceSummaries on your Reader with a backend-native summary query.
  2. At the call site, detect errors.Is(err, errUnsupported) and fall back to FindTraces + client-side aggregation, as the API documents.
  3. Feature-detect via a capability interface (type assertion to a summaries-supporting Reader) before requesting summaries.

Example fix

// before
summaries, err := reader.FindTraceSummaries(ctx, params) // err: ... does not compute trace summaries natively
// after
if summariesReader, ok := reader.(interface{ SupportsTraceSummaries() bool }); !ok || !summariesReader.SupportsTraceSummaries() {
    summaries = aggregateFromFindTraces(ctx, reader, params)
}
Defensive patterns

Strategy: fallback

Validate before calling

_, supportsSummaries := reader.(interface {
  FindTraceSummaries(context.Context, tracestore.TraceQueryParams) iter.Seq2[[]tracestore.TraceSummary, error]
})

Type guard

func supportsTraceSummaries(r tracestore.Reader) bool {
  _, ok := r.(interface {
    FindTraceSummaries(context.Context, tracestore.TraceQueryParams) iter.Seq2[[]tracestore.TraceSummary, error]
  })
  return ok
}

Try / catch

for summaries, err := range reader.FindTraceSummaries(ctx, params) {
  if err != nil {
    if errors.Is(err, errUnsupported) { // fall back to FindTraces + client-side aggregation
      return aggregateFromFindTraces(ctx, reader, params)
    }
    return err
  }
  _ = summaries
}

Prevention

When it happens

Trigger: Calling FindTraceSummaries on any Reader that embeds UnsupportedTraceSummaries instead of implementing the method — e.g. a ClickHouse or other v2 Reader lacking a summaries implementation.

Common situations: A UI or query service requests the trace-summary view against a backend without native summary support; plugin authors forget to implement FindTraceSummaries and embed the default; a newly added summaries API rolled out to some backends only.

Related errors


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