SigNoz/signoz · error

start and end must be unixnano time

Error message

start and end must be unixnano time

What it means

Validate() on the messaging-queues query request rejects requests whose Start or End timestamp is negative. Timestamps are expected as unix nanoseconds, so a negative value means the caller passed seconds/milliseconds, an unset zero-default that got decremented, or corrupted input. The check runs after Filters.Validate() as the final request sanity gate.

Source

Thrown at pkg/query-service/app/integrations/messagingQueues/queues/model.go:24

	v3 "github.com/SigNoz/signoz/pkg/query-service/model/v3"
)

type QueueListRequest struct {
	Start   int64         `json:"start"` // unix nano
	End     int64         `json:"end"`   // unix nano
	Filters *v3.FilterSet `json:"filters"`
	Limit   int           `json:"limit"`
}

func (qr *QueueListRequest) Validate() error {

	err := qr.Filters.Validate()
	if err != nil {
		return err
	}

	if qr.Start < 0 || qr.End < 0 {
		return fmt.Errorf("start and end must be unixnano time")
	}
	return nil
}

View on GitHub (pinned to 5069bf80b0)

Solutions

  1. Convert all timestamps to unix nanoseconds: use time.Time.UnixNano() (e.g. start := time.Now().Add(-1*time.Hour).UnixNano()).
  2. Never use -1 or other sentinels for Start/End; omit the field or use 0 with explicit range logic.
  3. Log the incoming raw Start/End at the API boundary to catch unit mismatches early.
  4. Add a client-side unit test asserting Start/End are positive nanosecond values.

Example fix

// before
qr.Start = time.Now().Add(-time.Hour).Unix()      // seconds -> can be fine, but mixing units underflows
qr.End = start - 3600                              // possibly negative

// after
qr.Start = time.Now().Add(-time.Hour).UnixNano()
qr.End = time.Now().UnixNano()
Defensive patterns

Strategy: validation

Validate before calling

func validUnixNanoRange(start, end int64) bool {
	return start >= 0 && end >= 0 && start <= end && start > int64(1e18) // nanosecond magnitude
}
if !validUnixNanoRange(qr.Start, qr.End) {
	return errors.New("timestamps must be unixnano: use time.Time.UnixNano()")
}

Type guard

func isUnixNano(t int64) bool { return t > int64(1e18) } // seconds ~1e9, ms ~1e12, ns ~1e18

Prevention

When it happens

Trigger: Calling Validate() on a MetricQueryRangeParams-style struct where qr.Start < 0 or qr.End < 0 — e.g. passing time.Now().Unix() (seconds) and then computing an offset that goes negative, or passing -1 sentinels for 'no time range'.

Common situations: Client sends epoch seconds or milliseconds instead of nanoseconds and a range calculation underflows to negative; frontend sends -1 as 'unset'; clock skew or misuse of time.Duration arithmetic producing negative values; porting code from a v1 API that used seconds.

Related errors


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