Added a test (spec?). It doesn't use the same setup as the other tests because it requires 2 variables to be created, but (with my limited understanding of frontend development) I would say it's sane.

Friendly ping.

Not sure about this as this looks like a breaking change.

Not breaking. I am loading dashboards saved before I made the change into a Grafana instance built with the patch and while /api/dashboards/file/collectd.json returns the value as "$__auto_interval", there is no console error in Chrome and the View JSON link on the dashboard shows the value as "$__auto_interval_period". It just works automagically.

If you are still concerned though, I could add code to look for an existing auto value (in addition to looking for a missing one, currently) and updating its value to the new format.

Any opinion? I'm willing to put in the grunt work.

Friendly ping.

I've tested the internal variable name change (unintentionally, as part of running various feature branches) for weeks now and have seen zero of errors (user visible or Chrome console). This is AFAICT because the internal $__auto_interval variable is only used in internal and serialized representations of dashboards and these are basically rebuilt on dashboard load.

Any chance of having this merged?

Or else, any guidance on what sort of explicit handling of auto interval variables you would like to see implemented before you'd merge this? Thanks.

Will old links with var-interval=$__auto_interval work ?

Thanks for bringing this up, I hadn't thought about it. I spent a bit of time checking and:

• Hardcoded (e.g. saved) links with var-interval=$__auto_interval will not work. The literal value $__auto_interval will be displayed in the dropdown (if the variable is not hidden) and will be passed in Prometheus queries. Curiously enough, if the dashboard has a refresh interval set, everything will automagically go back to normal on the first refresh.
• Generated links from dashboards having interval template variables saved with "value": "$__auto_interval" will work, as the value will be replaced at runtime with $__auto_interval_foo on dashboard load, and the generated links will have $__auto_interval_foo in them.

That was supposed to be:

Correctly handle old links with var-interval=$__auto_interval.

but I used double quotes when running git commit.

Anyway, this change is now fully backwards compatible, as interval variables with an auto value will now create 2 "hidden" variables, $__auto_interval_<var_name> and the legacy $__auto_interval. In case there are multiple auto interval variables, the last one will "win" and set the value of $__auto_interval, which is exactly the current behavior.

Codecov Report

Merging #9216 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9216   +/-   ##
=======================================
  Coverage   43.29%   43.29%           
=======================================
  Files         243      243           
  Lines       21449    21449           
  Branches      545      545           
=======================================
  Hits         9286     9286           
  Misses      11649    11649           
  Partials      514      514

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e91b00c...6c682cb. Read the comment docs.

This change is now fully backward compatible. Both the legacy $__auto_interval and a new $__auto_interval_<variable_name> are set and all of the internal logic relies on the latter. The former is only necessary for old (saved) links and may be (eventually) dropped in a future release.

Any chance of having it merged? It is literally 3 lines of code.

thanks for taking the time with this PR, sorry it takes a while for us to respond (and merge).