-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
feat(metrics_extraction): Always include the environment in the query hash #63774
feat(metrics_extraction): Always include the environment in the query hash #63774
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #63774 +/- ##
=======================================
Coverage 81.25% 81.25%
=======================================
Files 5234 5234
Lines 230469 230477 +8
Branches 45232 45234 +2
=======================================
+ Hits 187268 187280 +12
+ Misses 37362 37358 -4
Partials 5839 5839
|
df644bc
to
ce7ebb2
Compare
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.
Looks good, once you get tests passing then 👍
8f2c9db
to
b6b36ed
Compare
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.
I am lacking context of why we are adding the environment
now, but functionally speaking the PR LGTM!
…ollision (#64071) When merging specs, iterate over the widgets first. This will make sure that when an alert and widget specs collide, we will pick the spec of a widget which contains the environment in the tags. The next spec version in #63774 does not have this bug since the widget will always include the environment in the query hash, thus, it will not be possible for the alert spec to share the same query hash. This duplication of specs is the main reason that we still have some duplicated specs in [SENTRY-2EAS](https://sentry.sentry.io/issues/4888069767/).
# save us to look where to add this logic again | ||
spec_version = OnDemandMetricSpecVersioning.get_query_spec_version(self.organization_id) | ||
return OnDemandMetricSpec( | ||
return fetch_on_demand_metric_spec( |
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.
This change will make sure that the tests have the same function to get an OnDemandMetricSpec
from a Relay metric spec.
@@ -1430,6 +1444,27 @@ def _parse_query(value: str) -> QueryParsingResult: | |||
raise Exception(f"Invalid search query '{value}' in on demand spec: {e}") | |||
|
|||
|
|||
def fetch_on_demand_metric_spec( |
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.
This can now be used by the tests to have a single entry point to querying the right spec based on feature flags.
Jump to the end of tests/sentry/relay/config/test_metric_extraction.py
to see.
field = widget.aggregates[0] if widget.aggregates else "" | ||
return OnDemandMetricSpec( | ||
return fetch_on_demand_metric_spec( |
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.
I can now use this shared function to reduce differences between the code and the tests.
assert spec._query_str_for_hash == f"{expected_query_str_hash};['environment']" | ||
assert spec.query_hash == "4fb5a472" | ||
assert spec.spec_version.version == 2 | ||
assert spec.spec_version.flags == {"include_environment_tag"} |
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.
Compare it without having the feature flag (just above):
spec = _on_demand_spec_from_widget(default_project, widget)
assert spec.query_hash == "f1353b0f"
assert spec._query_str_for_hash == expected_query_str_hash
assert spec.spec_version.version == 1
assert spec.spec_version.flags == set()
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.
Looks good!
if features.has("organizations:on-demand-metrics-query-spec-version-two", org): | ||
return cls.spec_versions[1] | ||
return cls.spec_versions[0] | ||
|
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.
Not blocking, but doing this by array lookup is a little strange since that feature flag should only be for SpecVersion(2), I think this can be hardcoded, which will make cleanup more obvious as well.
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.
Yeah. I used to have a different approach that did not require any changes.
if ( | ||
self.spec_type == MetricSpecType.DYNAMIC_QUERY | ||
and self.spec_version.flags == set() |
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.
Not blocking; I don't know that we'll need this flag matching, it's pretty complicated, I can't see us needing a lot of individual behaviours and every new ability to a spec version will essentially reset the spec anyway.
exception = capture_exception.call_args.args[0] | ||
assert ( | ||
exception.args[0] | ||
== "Spec version 1: Too many (2) on demand metric widgets for org baz" | ||
== "Spec version 2: Too many (2) on demand metric widgets for org baz" |
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.
Okay so both spec version fail here and we're just checking the second one now?
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.
Both of them fail. I couldn't make up my mind. Perhaps I should not even take the version into consideration.
|
||
with Feature("organizations:on-demand-metrics-query-spec-version-two"): | ||
spec = _on_demand_spec_from_widget(default_project, widget) | ||
assert spec._query_str_for_hash == f"{expected_query_str_hash};['environment']" |
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.
This is specifically what we want for the new spec version, so 👍
…ollision (#64071) When merging specs, iterate over the widgets first. This will make sure that when an alert and widget specs collide, we will pick the spec of a widget which contains the environment in the tags. The next spec version in #63774 does not have this bug since the widget will always include the environment in the query hash, thus, it will not be possible for the alert spec to share the same query hash. This duplication of specs is the main reason that we still have some duplicated specs in [SENTRY-2EAS](https://sentry.sentry.io/issues/4888069767/).
… hash (#63774) Alerts and widgets are colliding since widgets only include the environment in the tags rather than in the query hash. This change will require 90 days of baking and then we will switch customers over and drop the old spec version. All widget extraction specs will double in number.
Alerts and widgets are colliding since widgets only include the environment in the tags rather than in the query hash.
This change will require 90 days of baking and then we will switch customers over and drop the old spec version.
All widgets will double in number.