Dashboards: multi value variables with backslash can't be used in KQL query with "in"

[SqlBenjamin]

What happened?

If I create a variable that is multi value and it has several items selected without a backslash in the values I can reference that variable in KQL queries using an "in" like this:
| where ColumnName in ($VarName)
However, if the column/variable has backslashes this does not work. Nor does using any of the options (that I've tried anyway), such as ${VarName:regex}.

I have tried a number of things to try to get this to work but can't seem to figure anything out that would work.

What did you expect to happen?

I would expect to be able to have an easy way to do something like | where ColumnName in ($VarName) or | where ColumnName in (${VarName:someoptionhere})

Did this work before?

I don't know.

How do we reproduce it?

1. create a variable in a dashboard that queries the distinct values in a table - where the column contains a backslash such as a filepath. Some simple values such as Something\1234, Bob\Loblaw, Hello\World would also work
2. Define the variable as multi-value and include the All option
3. create a visual that uses kql (ADE connection) to query the same table (or one you create with dummy values) that the variable does and in the query do something like TableName | where Column in ($VarName) (or some other option of that)
4. if you don't get an error I'd be surprised...but if you don't you likely won't get any data (even though the default at this point is "All" which should query everything in the table.

You can compare to something without a backslash by doing the same steps but using a column with values without a backslash.

Is the bug inside a dashboard panel?

No response

Environment (with versions)?

Grafana: Azure Managed Grafana (version 9.5.16)
OS: Windows 11
Browser: Microsoft Edge

Grafana platform?

Other

Datasource(s)?

Azure Data Explorer

[kaydelaney]

Seems like this might be Azure specific @grafana/partner-datasources

[aangelisc]

Hi @SqlBenjamin, thank you for opening this. I can confirm I've replicated the problem. It's due to the fact that the \ character is treated as a special character by KQL and requires escaping. Before we can implement a fix for this we'll need to confirm if there are any other characters that may require specific handling.

I'm also transferring this issue to the ADX repo as that's the data source you've referenced. Please let me know if this isn't the case.