Repository navigation
fix: a scalar answer carries its time in milliseconds, like Loki - #752
Conversation
⚪ Performance A/B: no change beyond noise26 shape×range — 26 ⚪ same · results vs Loki: 25 same, 0 new difference(s), 1 pre-existing Every shape is within noise of the base build (±30% and 100 ms). 26 unchanged shape×range (within noise)
Cold (first-run) timings — what a user opening a panel sees
Why these shapes
base |
✅ Visual smoke: passed with warningsBase Fix proofCaptures of the exact cases this pull request adds or fixes (registry case, base | PR | Loki). The verdict compares the PR with Loki where the base did not match. The gate fails a case unless one capture is fixed or improved, or, beyond the Loki data window, the base failed where Loki and the PR both answered with data (the label does not excuse it; only
Regression check
Gate: a base-vs-PR data difference passes when the PR is closer to Loki, and fails when the PR diverges from Loki or Loki cannot decide it (at a range Loki does not hold, a difference passes when the same page proved it closer to Loki at a shorter range; otherwise label the pull request dd-fields-1h: history-dependent difference, not gated (1): resource /api/datasources/uid/*/resources/patterns?end=2026-10-12T17%3A08%3
dd-service-logs-1h: history-dependent difference, not gated (1): resource /api/datasources/uid/*/resources/patterns?end=2026-10-12T17%3A08%3
dd-field-pipeline-1h: history-dependent difference, not gated (1): resource /api/datasources/uid/*/resources/patterns?end=2026-10-12T17%3A08%3
dd-field-service_version-1h: history-dependent difference, not gated (1): resource /api/datasources/uid/*/resources/patterns?end=2026-10-12T17%3A08%3
dd-labels-namespace-1h: history-dependent difference, not gated (1): resource /api/datasources/uid/*/resources/patterns?end=2026-10-12T17%3A08%3
All montages of this run: |
PR Quality ReportCompared against base branch Coverage and tests
Compatibility
Performance smokeLower CPU cost (
State
|
8d074b2 to
d646fa6
Compare
d646fa6 to
a0d242d
Compare
…seconds, like Loki Loki's query frontend writes a scalar through marshalScalar, which hands the millisecond timestamp to model.TimeFromUnix (seconds), so 1 answers [1791811168123,"1"] while vector(1) answers seconds. The proxy stamped scalars in seconds. Every scalar the proxy answers without a backend now carries the evaluation time as integer milliseconds; vector samples are unchanged. The e2e compares the sample time and value of each constant against Loki.
a0d242d to
f92077e
Compare








Summary
Follow-up to #735. On live Loki 3.7.7, a scalar answer such as
query=1&time=1791811168123456789returns its time as integer milliseconds:{"resultType":"scalar","result":[1791811168123,"1"]}. Avector(1)answer returns seconds:[1791811168.123,"1"]. #735 returned the scalar time in seconds.Why Loki returns milliseconds. The value comes from Loki 3.7.7's query-frontend encoding:
engine.go:700-702evalLiteral keeps the time in milliseconds.queryrange/marshal.go:97-112turns the scalar into aLokiPromResponsewithTimestampMs: v.T.queryrange/prometheus.go:163-176marshalScalar then builds the time withmodel.TimeFromUnix(TimestampMs).TimeFromUnixtakes seconds andTime.Stringdivides by 1000, so the millisecond count is printed as if it were seconds.marshalVector(prometheus.go:97-100) usesmodel.Time(TimestampMs)directly, which is why vectors stay in seconds.Fix. Scalar answers now carry integer milliseconds, as Loki does. That covers the constant instant answer and the scalar-op-scalar binary answer.
vector()answers stay in seconds.Tests
TestCompat_InstantResultTypeAlwaysSetcompares the time and value with Loki for1,-1,1 + 1,2 * (3 + 4),1 > bool 2,vector(1)andvector(1) + 2.loki=[1.791814361544e+12 1] proxy=[1.791814361544e+09 1].Notes
1/0and other literal divisions by zero answer HTTP 500 on Loki 3.7.7 after about 40 s. The query frontend cannot marshal NaN:grpc: error while marshaling: unsupported value: NaN. The proxy answers the scalarNaNthat Loki's ownMergeBinOpfold computes, and does not reproduce that internal error.1/0is left out of the e2e.query_rangescalar-op-scalar path still answers+Inffor1/0. fix: a division or modulo by zero is NaN, like Loki #745 makes it NaN.