{"record":{"id":"0d468343c7fd67fc","repo":"SigNoz/signoz","slug":"start-and-end-must-be-unixnano-time","errorCode":null,"errorMessage":"start and end must be unixnano time","messagePattern":"start and end must be unixnano time","errorType":"validation","errorClass":null,"httpStatus":400,"severity":"error","filePath":"pkg/query-service/app/integrations/messagingQueues/queues/model.go","lineNumber":24,"sourceCode":"\tv3 \"github.com/SigNoz/signoz/pkg/query-service/model/v3\"\n)\n\ntype QueueListRequest struct {\n\tStart   int64         `json:\"start\"` // unix nano\n\tEnd     int64         `json:\"end\"`   // unix nano\n\tFilters *v3.FilterSet `json:\"filters\"`\n\tLimit   int           `json:\"limit\"`\n}\n\nfunc (qr *QueueListRequest) Validate() error {\n\n\terr := qr.Filters.Validate()\n\tif err != nil {\n\t\treturn err\n\t}\n\n\tif qr.Start < 0 || qr.End < 0 {\n\t\treturn fmt.Errorf(\"start and end must be unixnano time\")\n\t}\n\treturn nil\n}\n","sourceCodeStart":6,"sourceCodeEnd":28,"githubUrl":"https://github.com/SigNoz/signoz/blob/5069bf80b08f1f00d7e014eccc09902f9871004f/pkg/query-service/app/integrations/messagingQueues/queues/model.go#L6-L28","documentation":"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.","triggerScenarios":"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'.","commonSituations":"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.","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."],"exampleFix":"// before\nqr.Start = time.Now().Add(-time.Hour).Unix()      // seconds -> can be fine, but mixing units underflows\nqr.End = start - 3600                              // possibly negative\n\n// after\nqr.Start = time.Now().Add(-time.Hour).UnixNano()\nqr.End = time.Now().UnixNano()","handlingStrategy":"validation","validationCode":"func validUnixNanoRange(start, end int64) bool {\n\treturn start >= 0 && end >= 0 && start <= end && start > int64(1e18) // nanosecond magnitude\n}\nif !validUnixNanoRange(qr.Start, qr.End) {\n\treturn errors.New(\"timestamps must be unixnano: use time.Time.UnixNano()\")\n}","typeGuard":"func isUnixNano(t int64) bool { return t > int64(1e18) } // seconds ~1e9, ms ~1e12, ns ~1e18","tryCatchPattern":null,"preventionTips":["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."],"tags":["validation","timestamp","unixnano","messaging-queues","api-contract"],"backgroundTag":"timestamp-unit-mismatch","analyzedSha":"5069bf80b08f1f00d7e014eccc09902f9871004f","analyzedAt":"2026-08-28T06:22:12.824Z","schemaVersion":2},"datasetVersion":"2026-08-28T11:17:15.048Z"}