-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand test coverage for cumulative and derived offset metrics #856
Conversation
These were all copy/pasted before and not really covering the reality of what the tests were doing.
Cumulative metric query rendering currently follows the same pattern as all other metrics, namely, we join -> filter -> aggregate. The problem is, if the filter specifies a restrictive time span, we may apply the filter on the inputs to the aggregations, which will produce incorrect cumulative metric outputs. This will happen in any case where the dimension `metric_time` is not incorporated into the query, as illustrated by the changes to the plan files for test_cumulative_metric_with_time_constraint. For now, we simply illustrate current behavior with the test cases in preparation for adding a validation enhancement to prevent bad queries from being processed. We will expand support for cumulative metric queries beyond metric_time in a follow-up.
Derived metric offsets handle time filters correctly provided the query depends on the `metric_time` dimension. Since the DataflowPlanBuilder has an invariant in its runtime to ensure that metric_time is included in the requested query specs, this is always true in practice. Additional tests for different query patterns may be warranted when we expand support. For the time being, we simply add an illustrative query rendering test for the behavior when filter spans are at odds with the offset window selection.
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was that you said about pokemon...? Caught them all ✨
Current test coverage for cumulative and derived offset metrics does not include
any tests of how we render queries with filters that do not allow us to do any
expansion on metric_time. This will be necessary as we add support for
detecting metric_time filter expressions and full predicate pushdown, as we will need
a way to verify that our logic is still rendering queries that will produce the correct results.
Worth noting, in this PR, that we currently have a number of rendering scenarios for
cumulative metrics where the queries are incorrect. As these are meant to be blocked by
query validation, I am leaving most of them intact, with the idea that when we properly
support those scenarios the rendering tests will update to reflect the fixes.