Add configurable Max query time range limit#9386
Conversation
|
@AdityaHegde : can you help review and take t his further ? |
| // isoDurationToDays approximates an ISO 8601 duration (e.g. "P90D", "P3M") in days, | ||
| // matching the executor's StandardDuration.EstimateNative() heuristic (1 month ≈ 30 days, 1 year ≈ 365 days). | ||
| // Returns NaN if the input cannot be parsed. | ||
| export function isoDurationToDays(isoDuration: string): number { |
There was a problem hiding this comment.
We shouldnt redo what rilltime already does for us. Lets use that instead. Note that this will add an additional query. We can instead return it in MetricsViewTimeRange/MetricsViewTimeRanges if max_query_time_range is defined on metrics view.
With this change most components should take luxon.Interval and use that to calculate caps.
|
|
||
| // rangeWithinCap returns true unless the range can be statically sized to more than maxRange. | ||
| // rill-time expressions and unparseable inputs pass through; the backend has the final say. | ||
| function rangeWithinCap(range: string, maxRange: Duration): boolean { |
There was a problem hiding this comment.
Do we still need this? If we use API to resolve ranges then we can also support rilltime syntax.
There was a problem hiding this comment.
We can take this a future enhancement. Getting the API response in can be tricky.
| return nil, ErrForbidden | ||
| } | ||
|
|
||
| mv, _, err := resolveMVAndSecurity(ctx, s.runtime, req.InstanceId, req.MetricsViewName) |
There was a problem hiding this comment.
nit: can just do lookupMetricsView(ctx, s.runtime, req.InstanceId, req.MetricsViewName) instead of this as only mv spec is needed, security is not used.
nishantmonu51
added
the
blocker
…board-max-time-range # Conflicts: # proto/gen/rill/runtime/v1/resources.pb.go
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Add configurable Max query time range limit * Fix prettier * Handle review comments * Fix CI * add file * Fix lint * Handle review comments * Regenerate proto files after merging main Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 participants
Today a user can ask a metrics view to aggregate data over an arbitrarily wide time range.
For datasets with high cardinality or fine-grained time dimensions this is expensive and can starve the OLAP engine.
This PR introduces a per-metrics-view safety cap: a maximum time span that any single interactive query can cover (e.g., "no query may span more than 90 days").
It is configurable max time range limit on the metrics view.
Checklist: