-
Notifications
You must be signed in to change notification settings - Fork 12.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
Dashboards: Regression on InfluxQL query variable: found $, expected ) #80003
Comments
Ps. Also the gauge panels that did work with Grafana 10.2.2 are now too big to fit / display (this use to fit without any issues, but for some reason the upgrade caused the gauge to no longer fit the content). See: Regression of: #76216 ? |
^ cc @itsmylife |
I get the same InfluxQL Query error with 2.10.3 |
Hey, a temporary fix for the initial issue would be to modify the query and how the variable is used from "/^$hostname$/" to "/^${hostname:regex}$/". That seemed to fix it for me |
Looks like the problem here is that we're not properly formatting regex tag values on the backend for queries that are created in the visual builder. We're currently formatting regex tag values as |
That's what I was seeing as well @gtk-grafana. Just cross posting what I had shared in another issue:
|
Set |
@melroy89 yes disabling the flag is going to be the best workaround for now. We'll update this issue when a fix has been merged. |
I don't think the issue is limited to regex values. I'm getting the same/similar error with a variable used for a simple exact match. There seems to be an escaping mismatch between encoding and decoding. I have a query
which gets sent as JSON like
The hostname here isn't (un)escaped properly.
Not sure it's the same as or related to #77465, since that one mentions an issue when upgrading from 10.1.x, while it's working for me with 10.2.2 |
The Gauge display also broke for me but changing the Orientation from Horizontal to Auto fixed it. |
@pprkut Good catch, yes there appears to be two different (but similar) problems which is causing some confusion. Regex variables are not escaping values containing the regex delimiter The workaround for this issue is to disable the AND there is a regression in 10.2.3 that isn't related to the backend migration, but variable interpolation for raw influxdb queries are being escaped when they weren't in 10.2.2. The fix for this issue is to revert back to 10.2.2, although I can verify @iBug's workaround above does work, but I don't want to recommend that folks change their dashboards because of an unintentional change like this. I would expect we can release/backport a fix out for both of these in 10.3.1 as we just missed the 10.3 cutoff. Thanks to everyone for your reporting/investigating/patience |
Hi, The issue is still happening to me on 10.3.1. @iBug workaround still works. Thanks, |
The PR #80971 is going to resolve all interpolation issues. It is targeting 10.4.x. |
Thank you for fixing all the regression issues. |
What happened?
On the latest Grafana version I have regression with InfluxDB with InfluxQL.
path
variable is not empty, but still gives an error in the query (however, this used to work fine.. ):When manually selecting a path without the use of the variable it does work:
Console log:
What did you expect to happen?
No errors on this query, it's a valid InfluxQL query.
Did this work before?
I use set this
path
as variable in InfluxQL together with the repeat feature, so I repeats for each of the selected mount/paths. This used to work fine on older Grafana versions.How do we reproduce it?
path
with the query:SHOW TAG VALUES FROM "disk" WITH KEY = "path"
path
variable as well.InfluxDB returned error: error parsing query: found $, expected ) at line 1, char 98
Is the bug inside a dashboard panel?
Panel debug snapshot dashboard
Environment (with versions)?
Grafana: 10.2.3 (recent version seems to cause issues!)
OS: Ubuntu Server 22.04 LTS
Browser: Firefox
Grafana platform?
A package manager (APT, YUM, BREW, etc.)
Datasource(s)?
Telegraf
Related PRs
I'm just guessing here. But this could be regression of either: #77917 or #77799 (or even maybe maybe: #78834) or just something else.. I'm again not sure.
The text was updated successfully, but these errors were encountered: