[Nwapu-TrustJah]

Summary

Standardized all range queries across the codebase from inclusive upper bounds (<=) to half-open intervals [from, to) (<) to prevent double-counting samples on shared boundaries. Updated OpenAPI specifications and added a dedicated adjacent-window test suite.

Related issue

Closes #236

Type of change

• Bug fix
• New feature
• Refactor
• Docs
• Tests

[drips-wave]

@Nwapu-TrustJah Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

Three type errors on its own branch against current main — npx tsc --noEmit will show them after a rebase.

Standardising range queries to half-open intervals [from, to) is the right call and worth doing properly: with closed intervals, consecutive windows double-count the boundary row, which quietly inflates every volume and count that straddles it. That is the kind of error nobody notices because the number still looks plausible.

Worth adding a test that pins exactly that, if there is not one already: two adjacent windows over a row that sits on the boundary should total the same as one window covering both.

[Nwapu-TrustJah]

​I have completed all the requested changes:
​Rebased onto main and fixed the TypeScript compilation errors (npx tsc --noEmit passes clean).
​Standardized range queries to half-open intervals [from, to) across all endpoints.
​Added unit tests (windowBoundaries.test.ts) confirming that adjacent windows equal a single combined window without boundary double-counting. All tests are passing.
​Ready for re-review whenever you get a chance!

[Miracle656]

Merged to main as 431bb87. The three type errors are gone, and you added exactly the test I asked for.

src/__tests__/windowBoundaries.test.ts is what made this mergeable rather than merely plausible — "counts a sample landing exactly on the boundary exactly once" and "excludes the boundary sample from the earlier window and includes it in the later one", asserted for both routes. That pins the invariant rather than restating the change, which is the difference between a test that proves a fix and one that documents it.

The network predicate is the bigger fix and it isn't in your title. The changeset is where I found it: /candles and /basket were reading rows from both chains, and /benchmark was computing its deviation figures from both. A pair's price being a blend of mainnet and testnet is worse than the boundary double-count, and far harder to notice. Worth putting that in the PR title next time — I nearly reviewed this as a one-line interval change. The comments explaining that price_points indexes network as the leading column of (network, pair_key, timestamp), so the predicate is needed for the index as well as for correctness, are the right thing to leave behind.

The breaking-change note is also well written: saying plainly that callers relying on the inclusive end must widen to by one tick, with a worked example at interval=1m, is what a consumer actually needs.

One follow-up, deliberately out of scope here. Two closed-interval predicates remain:

• src/api/graphql.ts:338 — bucket <= $N
• src/routes/movers.ts:89 — timestamp <= $3

So GraphQL priceHistory and /movers now disagree with the REST routes about the same data. graphqlPriceHistory.test.ts:216 pins the closed form, so changing it is a deliberate decision that needs its own breaking note rather than something to slip into this PR. Flagging it so the inconsistency is a known one rather than a surprise — happy to take it as a follow-up if you want it.

Lens: 114 files, 1,411 tests passing, typecheck clean.