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
- Convert all timestamps to unix nanoseconds: use time.Time.UnixNano() (e.g. start := time.Now().Add(-1*time.Hour).UnixNano()).
- Never use -1 or other sentinels for Start/End; omit the field or use 0 with explicit range logic.
- Log the incoming raw Start/End at the API boundary to catch unit mismatches early.
- 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
- Always build Start/End with time.Time.UnixNano().
- Reject or normalize -1 sentinels at the API boundary.
- Add a middleware assertion that time-range params exceed 1e18 to catch unit mixups.
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
- consumer_group not found in the request
- partition not found in the request
- invalid type for Topic
- invalid type for Partition
- startTimeMillis is required
AI-assisted analysis of SigNoz/signoz@5069bf80b0 (2026-08-28).
Data as JSON: /api/errors/0d468343c7fd67fc.
Report an issue: GitHub.