Redash: missing value for commented out parameter

[a-stepaniuk]

I receive error Error running query: missing value for ... parameter. although the parameter itself is commented out in script.
When I delete the commented out section I receive no errors.

I should not receive an error for missing parameter when parameter is not actually used in the query.

[arikfr]

Thank you for reporting this! Redash is agnostic to the query being executed -- we pass it as is (except for applying parameters) to the data source. Therefore we don't know if the parameter is commented out or not and need to verify it has a value.

I don't think this will change in the near future.

The workaround in this case is simple: either provide a value for this parameter or just remove it from the query.

As we keep only actionable issues, I'm going to close this one. But don't hesitate following up if you want to share more thoughts on this.

[justinclift]

Just came across this while investigating stuff.

As an example query, lets say I'm starting with this:

SELECT foo, bar, baz
FROM query_1
WHERE Category = 'Cloth'
GROUP BY 1, 2;

No query parameters there. But, lets say the WHERE Category line is turned into one:

SELECT foo, bar, baz
FROM query_1
WHERE Category = {{ Category }}
GROUP BY 1, 2;

When the parameter is added to the query, the parser recognises it then triggers an update to the browser DOM to include a query parameter piece for adding appropriate details (possible values, etc).

Commenting it out though "doesn't work":

SELECT foo, bar, baz
FROM query_1
-- WHERE Category = {{ Category }}
GROUP BY 1, 2;

Although the query parser/tokeniser clearly recognise that line is a comment (thus changing colour of it in the text field), nothing is triggered to remove the query parameter piece from the DOM.

And the 'Error running query...' value as reported here happens.

The parser/tokeniser recognises when a line is commented, as it recognises query parameters being added to the SQL. It should then strip out commented lines before passing them on to the data source.

2885 seems to be the same thing, just simplified. :smile:

[ranbena]

Technically, we can determine commented out params with a simple regex while keeping the agnostic approach.

[justinclift]

Thinking about this more earlier, probably the "ideal" behaviour here would be for the query parameter DOM widget (not sure of the correct terminology yet) to be greyed out when it's matching parameter in the SQL is.

Conversely, if/when the query parameter in the SQL is uncommented, then the matching widget would be usable again.

From a logical perspective, that seems like it'd be consistent. :smile:

[gabrieldutra]

Thinking about this more earlier, probably the "ideal" behaviour here would be for the query parameter DOM widget (not sure of the correct terminology yet) to be greyed out when it's matching parameter in the SQL is.

Agreed, the parameters should be disabled (with a tooltip?) :). Parameter
disappearance may be an unwanted behaviour. It was common to comment those
pieces of SQL to "debug" a query and with parameters disappearing it may
feel like they lost their Settings (in this case it's a lot better to see
they are still there at least for the source view context).