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
Azure Monitor: Fix migration issue with MetricDefinitionsQuery template variable query types #55262
Conversation
@@ -295,6 +298,7 @@ const migrateGrafanaTemplateVariableFn = (query: AzureMonitorQuery) => { | |||
break; | |||
} | |||
|
|||
delete migratedQuery.grafanaTemplateVariableFn; |
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 sure if this was left on purpose (maybe to track migrations or roll back?)
If no reason then I think removing it makes the panel JSON cleaner
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 also a safety measure, if for some reason the migration is not correct, if the old information is there it could be run again. In any case, I think it's safe to remove it in this case.
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.
Removing it breaks almost every test in variables.test.ts
with timeout errors 🤔 That's why I added it back, do you have any idea why that is?
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.
those tests use this method:
observables.subscribe((result: DataQueryResponseData) => {
expect(result.data[0].source).toEqual(expectedResults);
done();
});
if the expect
fails, done
is never called so the test hangs until reaching the timeout. If you scroll, you should be able to see the real error.
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.
Yes, I get a Cannot read properties of undefined (reading 'source')
meaning result.data[0]
is undefined there.
I tried logging the result but got nothing back 🤔
I don't see how that could relate to removing the grafanaTemplateVariableFn
property 🤷♀️ .
Should I merge without the delete
for a quick fix? Or you think it could mean there is another bug hidden somewhere that the delete surfaces?
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 haven't checked the code but that probably means that grafanaTemplateVariableFn
is used elsewhere (either in functional code or in the test). But since there is no need to remove the property I would merge this as it is.
Drone build failed: https://drone.grafana.net/grafana/grafana-enterprise/33685 |
Backend code coverage report for PR #55262 |
Frontend code coverage report for PR #55262
|
Drone build failed: https://drone.grafana.net/grafana/grafana-enterprise/33719 |
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.
LGTM
@@ -258,7 +258,7 @@ const migrateGrafanaTemplateVariableFn = (query: AzureMonitorQuery) => { | |||
return query; | |||
} | |||
|
|||
const migratedQuery: AzureMonitorQuery = { |
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 still be a const?
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.
Indeed, I thought I had to change it when I had the delete
for grafanaTemplateVariableFn
but you're right 👍
@@ -43,6 +43,13 @@ export interface MetricNamespaceQuery extends BaseGrafanaTemplateVariableQuery { | |||
metricNamespace?: string; | |||
resourceName?: string; | |||
} | |||
export interface MetricDefinitionsQuery extends BaseGrafanaTemplateVariableQuery { |
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.
can you add a /* @deprecated
message?
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.
Good point
@@ -822,7 +822,7 @@ | |||
"options": [], | |||
"query": { | |||
"grafanaTemplateVariableFn": { | |||
"kind": "MetricDefinitionsQuery", | |||
"kind": "MetricNamespaceQuery", |
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.
usually it's good to leave these queries as the "old" way to check if we break migrations but for this case I guess it's okay to update them.
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 guess it did not help us spot that we did break migrations ;)
I would rather update them in case someone uses them as template to create another curated dashboard.
But we could leave one (not importable) and use it in the tests...
WDYT?
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.
yep, it's not automated so it's difficult to catch errors ... but it's helpful to reproduce issues :) anyway I also get your point for people using these as templates so it's also fine to update them.
Drone build failed: https://drone.grafana.net/grafana/grafana-enterprise/33730 |
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.
Nice work!
…te variable query types (#55262) (#55359) * updated imported dashboards * Adds check for MetricDefinitionsQuery in migration * Removed delete from migratio * switched back to const for migratedQ * Added depreacted to MetricDefinitionQuery (cherry picked from commit 1e9f5a5) Co-authored-by: Yaelle Chaudy <42030685+yaelleC@users.noreply.github.com>
What this PR does / why we need it:
The new migration does not take into account
MetricDefinitionsQuery
type and if a template variable had thatkind
property, clicking on it in the template variables view triggers an infinite loop and the browser crashes.This PR adds back the type thus fixing the issue
As
MetricDefinitionQuery
was removed previously by us, I also updated the imported dashboards to reflect that changeWhich issue(s) this PR fixes:
Fixes escalation #3850
Special notes for your reviewer: