Repository navigation
fix(query-engine): charts span the service pages' longest presets - #2325
Confidence 6/10 · 1 issue to address
🟡 Confidence 6/10 · needs attention. Held at 6 because a performance warning is open.
1 warning −1 · 1 note · tests partial −1 · risk medium
Gives timeseries charts a 367-day ceiling so the service pages' 12-month presets stop failing, and shares it with the services facets. The widening also reaches sources with no year-long rollup (metrics_*, product_events), which now accept raw scans that were previously refused.
MAX_TIMESERIES_RANGE_SECONDS(367 days) replaces the 31-day ceiling for timeseriesvalidateTimeRangetakes amaxRangeSecondsargument defaulting to the general ceiling- Services facets get the wide ceiling through
executeRangeCeiling - Alerts and the public v2 endpoints keep 31 days
Findings
🟠 Warning · F1 · executeRangeCeiling widens timeseries over raw metrics and product_events
performance · packages/query-engine/src/runtime/query-engine.ts:850-852
Every timeseries now passes the 367-day ceiling, but only traces reads a 365-day rollup. A 12-month window over metrics_* (90-day retention) or product_events (365-day fact table, queried raw) used to fail fast and now scans up to a year of rows in one query. The limits comment claiming rollup-less sources keep 30 days does not hold for either.
Gate the wider ceiling on the timeseries sources that read a 365-day rollup (e.g. `query.source === "traces"` plus the services facets) and leave `metrics`, `logs` and `product_events` on `MAX_QUERY_RANGE_SECONDS`.
🔵 Note · F2 · facets/services half of executeRangeCeiling has no test
tests · packages/query-engine/src/runtime/query-engine.ts:850
The added tests cover a 12-month timeseries and a 3-month breakdown. Nothing pins the second arm of this condition: that the services facet rail is allowed a year while facets on traces, logs and errors stays at 31 days, which the services list page now depends on.
Add a case executing `{ kind: "facets", source: "services" }` over 12 months, and one keeping `{ kind: "facets", source: "traces" }` at the general ceiling.
Production impact
Production traffic of the changed files (last 7 days)
| File | Calls/day | Busiest operations |
|---|---|---|
packages/query-engine/src/runtime/query-engine.ts |
170k | QueryEngineService.validateTimeRange 163k/day, 0.0% errQueryEngineService.validateTimeRange 3.0k/day, 0.0% errQueryEngineService.validateExecute 2.8k/day, 0.0% err |
What was checked
- 12-month arithmetic holds: 366 days plus a DST hour is under 367 (
limits.ts:24), andcomputeBucketSecondspicks 86400 for a year — 367 points, underMAX_POINTand on the hourly rollup tier list(7d) andbreakdown(30d) ceilings andvalidateEvaluate's 31-day default are untouched- Both web and v2 paths reach
validateExecute: the internal/executeroute has no range cap of its own; v2parseWindowstill enforces 31 days (telemetry.http.ts:531)
032ac1d · Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.
Annotations
Check warning on line 852 in packages/query-engine/src/runtime/query-engine.ts
maple-review-bot / Maple / review
performance: `executeRangeCeiling` widens timeseries over raw `metrics` and `product_events`
Every timeseries now passes the 367-day ceiling, but only `traces` reads a 365-day rollup. A 12-month window over `metrics_*` (90-day retention) or `product_events` (365-day fact table, queried raw) used to fail fast and now scans up to a year of rows in one query. The limits comment claiming rollup-less sources keep 30 days does not hold for either.
Check notice on line 850 in packages/query-engine/src/runtime/query-engine.ts
maple-review-bot / Maple / review
tests: `facets`/`services` half of `executeRangeCeiling` has no test
The added tests cover a 12-month timeseries and a 3-month breakdown. Nothing pins the second arm of this condition: that the services facet rail is allowed a year while `facets` on traces, logs and errors stays at 31 days, which the services list page now depends on.