Uh oh!
There was an error while loading. Please reload this page.
Align yrate/yincrease/ydelta with Prometheus 3.x (start, end] semantics - #20
Open
ColinDKelley wants to merge 2 commits into
Open
Align yrate/yincrease/ydelta with Prometheus 3.x (start, end] semantics#20ColinDKelley wants to merge 2 commits into
ColinDKelley wants to merge 2 commits into
Conversation
ColinDKelley
changed the base branch from
invoca-2.55.x/add-yrate
to
invoca-2.55.1/add-yrateApril 19, 2026 01:35
ColinDKelley
marked this pull request as ready for review
July 8, 2026 23:14
ColinDKelleyforce-pushed
the
invoca-2.55.1/align-yrate-to-3x-range-boundary
branch
from
July 8, 2026 23:16
4bf7c40 to
fc4e2f3Compare24 tasks
ColinDKelleyforce-pushed
the
invoca-2.55.1/add-yrate
branch
from
July 9, 2026 22:27
f9a1dbd to
9483ce1CompareColinDKelleyforce-pushed
the
invoca-2.55.1/align-yrate-to-3x-range-boundary
branch
4 times, most recently
from
July 10, 2026 00:22
ac82c0a to
366ca82CompareFlip the yrate-family range convention from [start, end) to (start, end] so that a sample whose timestamp lands exactly on a range boundary is attributed to the later range, never to both or neither. This matches the convention adopted upstream in Prometheus 3.x (see prometheus#13213). The xrate family, whose legacy [start, end] convention predates this decision, is unaffected. Behavior change is confined to samples that land precisely on a range boundary; all existing yrate test cases use shifted eval times to avoid boundary alignment, so only the "Comparison of rate vs xrate" showcase (which intentionally evaluates on boundaries at 25s and 75s) observes a difference. The linearity property yIncrease(p0) + yIncrease(p1) == yIncrease(p0 + p1) is preserved under the new semantics. Made-with: Cursor
Three values in the "Comparison of rate vs xrate" showcase change under the new yrate range convention, all on boundary-aligned evals: eval 25s yrate[50s] /bar: 0.1 -> 0.12 (sample at t=25 now in range) eval 75s yrate[50s] /foo: 0.06 -> 0.02 (sample at t=25 now attributed eval 75s yrate[50s] /bar: 0.22 -> 0.1 to the prior range) These changes are the intended effect of attributing a boundary sample to the later range rather than the earlier one. All other yrate/ yincrease/ydelta cases (big 1000+/2000+ block, counter-reset block, ydelta block) use shifted eval times and are unaffected. Made-with: Cursor Co-authored-by: Cursor <cursoragent@cursor.com>
ColinDKelleyforce-pushed
the
invoca-2.55.1/add-yrate
branch
from
July 10, 2026 02:27
bf2d555 to
8dba4ffCompareColinDKelleyforce-pushed
the
invoca-2.55.1/align-yrate-to-3x-range-boundary
branch
from
July 10, 2026 02:27
366ca82 to
8e94af7Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Flip the yrate family (
yrate/yincrease/ydelta) range convention from[start, end)to(start, end]so that a sample whose timestamp lands exactly on a range boundary is attributed to the later range, never to both or neither.Stacked on top of #22 (
invoca-2.55.1/add-yrate).Why now
Prometheus 3.x standardized on
(start, end]for PromQL range selectors (see prometheus/prometheus#13213). This PR pre-aligns our yrate family with that convention so that when we eventually merge up to 3.x, yrate keeps producing the "right" answer under the same semantics the rest of the engine uses.The xrate family, whose legacy
[start, end]convention predates this decision, is deliberately untouched — its showcase tests exist to document that legacy behavior.What changes
promql/functions.go:yIncreaseloop now iteratest <= rangeEndMsecand treatst > rangeStartMsecas "in range". Docstrings onyIncreaseandrangeFromSelectorsupdated with the new convention and a reference to upstream promql: Make range selections left-open and right-closed prometheus/prometheus#13213.promql/promqltest/testdata/functions.test: three expected values in the "Comparison of rate vs xrate" showcase change — the only test cases in the repo that intentionally evaluate on boundary-aligned timestamps (25s and 75s with a 5s collection cadence)./bar/foo/barlastBeforeRangeAll other yrate test cases — the big 1000+/2000+ block, the counter-reset block, and the
ydeltablock — use shifted eval times (49s, 29m, 24m, 19m) specifically to avoid boundary alignment, and are unchanged.The linearity property
yIncrease(p0) + yIncrease(p1) == yIncrease(p0 + p1)is preserved under the new semantics.Test plan
go build ./...(clean)go test -count=1 ./promql/...(all green, including showcase and ported 2.39.2 cases)