jaegertracing/jaeger · error

min start time is above max

Error message

min start time is above max

What it means

ErrStartTimeMinGreaterThanMax is returned by validateQuery when the query's StartTimeMax is before StartTimeMin, i.e. the requested time window is inverted. The badger reader builds byte-comparable timestamp keys from these bounds, so an inverted range would match nothing and is rejected up front.

Source

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

	"math"
	"slices"

	"github.com/dgraph-io/badger/v4"
	"golang.org/x/exp/maps"

	"github.com/jaegertracing/jaeger-idl/model/v1"
	"github.com/jaegertracing/jaeger/internal/storage/v1/api/spanstore"
	"github.com/jaegertracing/jaeger/internal/storage/v2/api/tracestore"
)

// Most of these errors are common with the ES and Cassandra backends. Each backend has slightly different validation rules.

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")

View on GitHub (pinned to 806f444784)

Solutions

  1. Swap or recompute the bounds so StartTimeMin < StartTimeMax before calling.
  2. Validate ordering client-side and reject the request early with a clear message.
  3. If the range is legitimately empty (e.g. zero-length window), short-circuit and return an empty result without querying.

Example fix

// before
q := &spanstore.TraceQueryParameters{StartTimeMin: end, StartTimeMax: start} // inverted
ids, err := reader.FindTraceIDs(ctx, q)
// after
if start.After(end) {
	start, end = end, start
}
q := &spanstore.TraceQueryParameters{StartTimeMin: start, StartTimeMax: end}
ids, err := reader.FindTraceIDs(ctx, q)
Defensive patterns

Strategy: validation

Validate before calling

if q != nil && !q.StartTimeMax.IsZero() && q.StartTimeMax.Before(q.StartTimeMin) {
	return errors.New("StartTimeMax must be after StartTimeMin")
}

Type guard

func hasValidTimeWindow(q *spanstore.TraceQueryParameters) bool {
	return q != nil && !q.StartTimeMin.IsZero() && !q.StartTimeMax.IsZero() &&
		q.StartTimeMin.Before(q.StartTimeMax)
}

Try / catch

ids, err := reader.FindTraceIDs(ctx, q)
if errors.Is(err, spanstore.ErrStartTimeMinGreaterThanMax) {
	return nil, httpError(400, "time range is inverted: start must precede end")
}
if err != nil { return nil, err }

Prevention

When it happens

Trigger: FindTraceIDs/FindTraces with TraceQueryParameters where StartTimeMax.Before(StartTimeMin) — typically from swapped arguments, a client computing min/max in the wrong order, or timezone/clock conversion mistakes.

Common situations: UI date pickers sending start > end; callers reversing parameter order in helper wrappers; automated scripts computing window boundaries from separate clocks with skew.

Related errors


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