grafana "textbox" variable is put into quotes from 0.21.4 on

[localpref]

Describe the bug

I have been using (besides a lot of grafana multi-select vars) a grafana variable of type "textbox" to add ad-hoc filters to a dashboard, i.e. my queries look like

_stream: {source_type in ("syslog", "socket")}
  AND baz: in($baz_fields)
  AND foobar: in($foo_fields)
  $textbox_filter

where I could put logsQL like parsed.appname: in(a,b) AND hostname: acme* into the textbox and have it appended to the filter verbatim, which is nice as all my graphs & bars update as they use the same filter query. A change between 0.21.1 and 0.21.4 started quoting all variable expansions, so this becomes "parsed.appname: in(a,b) AND hostname: acme*", forcing LogsQL to search for the literal string instead of the actual LogsQL query it is supposed to be. Before, I was free to use " myself if I had certain literal parts in my free-form filter.

I would like to exempt textbox-type variables from the "must be quoted" rule - I understand the quoting was added around some corner cases with length-1-lists etc, and in every place we work with (non-custom!) values from a grafana variable I would agree with that, but for textbox I would disagree. As it is, this patch took functionality away for me, making it far less useful (because even though I can take the query to explore or vmui and do my filtering there, but that will not update my whole dash with all the graphs) than with 0.21.1.

Alternatively, some form of magic prefix or suffix that unquotes would work for me, e.g. instead of $textbox_filter, $##noqoute##textbox_filter? I realise that my use case might be uncommon (but, as I said, it is very useful)

Re-reading this, I think maybe the difference can be put into "custom" vs "calculated" fields? For everything that comes from a grafana query of sorts ("calculated"), quoting is probably the right thing to do, but for custom fields (where textbox is a prime example, but multi-select vars can also have custom values, and some custom lists as well) a case could be made that necessary quoting could be put onto the user's decision.

To Reproduce

add a grafana textbox variable and reference it in a LogsQL query. Quoted in 0.21.4, unquoted in 0.21.1

Versions of VictoriaLogs datasource and VictoriaLogs backend

worked in v0.21.1, stopped working from v0.21.4

Link to dashboard in Victoria Metrics

No response

Please provide dashboard JSON if it is possible

No response

Additional information

No response

[arturminchukov]

@localpref thanks for bug report!
I think that this issue will fix that problem. I checked it locally, so the fix will be available with the release v0.22.1.

[localpref]

@arturminchukov
just tested with v0.22.1 - you might want to hold off releasing that to grafana, as an empty textbox gives me $_StartMultiVariable__EndMultiVariable in the final query, breaking everything in the process :)
once I enter data into the textbox, it works like I want it to again, i.e. unquoted.

[arturminchukov]

@localpref thanks for the notice, will fix it

[pgassmann]

We also use a dashboard with a Textfield as $log_query variable, which is just appended to the query.

with $log_query Text field set to ~"uccess"

the test query: ~"uccess" $log_query

becomes: ~\"uccess\" \"~\\\"uccess\\\"\" (inspector view) in datasource v0.21.2+
should be: ~\"uccess\" ~\"uccess\" (v0.21.1)

full request of request in inspector (v0.21.4):

  "request": {
    "url": "api/ds/query?ds_type=victoriametrics-logs-datasource&requestId=SQR101",
    "method": "POST",
    "data": {
      "queries": [
        {
          "datasource": {
            "type": "victoriametrics-logs-datasource",
            "uid": "P93BASDF"
          },
          "editorMode": "code",
          "expr": "category:in(dockerlogs) AND host:in(\"test01\",\"test02\",\"test03\",\"testarch01\") AND compose_project:in(qual) AND compose_service:in(*) ~\"uccess\" \"~\\\"uccess\\\"\"\n| sort\n# format outputs with color codes\n| format \"\\033[33m<host>\\033[0m:\\033[36m<compose_project>\\033[0m/\\033[96m<compose_service>\\033[0m\\t<_msg>\" as _msg | sort by (_time) desc",
          "legendFormat": "{{ compose_service }}",
          "queryType": "instant",
          "refId": "A",
          "maxLines": 5000,
          "extraFilters": "",
          "datasourceId": 51,
          "intervalMs": 5000,
          "maxDataPoints": 1959
        }
      ],
      "from": "1764052796256",
      "to": "1764063596256"
    },
    "hideFromInspector": false
  },

I tried all the versions between 0.21.0 and 0.21.4. The regression starts with 0.21.2
downgrading datasource to v0.21.1 fixed the issue for now.

full request of request in inspector (v0.21.1):

"request": {
    "url": "api/ds/query?ds_type=victoriametrics-logs-datasource&requestId=SQR102",
    "method": "POST",
    "data": {
      "queries": [
        {
          "datasource": {
            "type": "victoriametrics-logs-datasource",
            "uid": "P93BASDF"
          },
          "editorMode": "code",
          "expr": "category:in(dockerlogs) AND host:in(test01,test02,test03,testarch01) AND compose_project:in(qual) AND compose_service:in(*) ~\"uccess\" ~\"uccess\"\n| sort\n# format outputs with color codes\n| format \"\\033[33m<host>\\033[0m:\\033[36m<compose_project>\\033[0m/\\033[96m<compose_service>\\033[0m\\t<_msg>\" as _msg",
          "legendFormat": "{{ compose_service }}",
          "queryType": "instant",
          "refId": "A",
          "maxLines": 5000,
          "extraFilters": "",
          "datasourceId": 51,
          "intervalMs": 5000,
          "maxDataPoints": 1959
        }
      ],
      "from": "1764052094429",
      "to": "1764062894429"
    },
    "hideFromInspector": false
  },

[arturminchukov]

@localpref @pgassmann , The issue was fixed in the v0.22.3 plugin version. Close the issue as fixed. If you find any problems, feel free to reopen the issue.