`DataExplorer::ValidationError: Missing parameter` when running Data Explorer queries with [params] via API

Data & reporting
,
1

There is a bug in Discourse API when running Data Explorer queries containing parameters (both queries below work as expected when run from the browser).

Following the instructions from Run Data Explorer queries with the Discourse API and using

-F 'params={"group_id":"64"}'

to run this query (which has a parameter without its default value set)

-- [params] -- int :group_id select id, name from groups where id = :group_id

results in an error: {"success":false,"errors":["DataExplorer::ValidationError: Missing parameter group_id of type int"]}

When a query has a parameter with its default value set, the API call is successful, but the result is the same regardless of the value provided via -F 'params=

-- [params] -- int :group_id = 2 select id, name from groups where id = :group_id 
-F 'params={"group_id":"64"}'

and it always returns the result for the default value of the parameter: {"success":true,"errors":[],"duration":0.2,"result_count":1,"params":{},"columns":["id","name"],"default_limit":1000,"relations":{},"colrender":{},"rows":[[2,"moderators"]]}

2

What is the complete command you’re using?
Are you supplying -X POST and all the required headers?

3

The browser uses the API. It’s improbable that you are describing a big if discourse.

4

The one from How to run Data Explorer queries with the Discourse API complete with -X POST and all the required headers.

This is not a syntax issue, if you check the last line from the OP you’ll see that curl returns a success, it’s just that the result is incorrect.

Jay, I don’t understand the meaning of this sentence. Did you by any chance try and repro the issue using the minimal examples provided in the OP?

@michaeld, @pfaffman
I’m hesitating to write this part, mainly because I admire and respect your dedication and expertise in providing free support to the community, I know I benefited from your insights on numerous occasions before. But this time I have a feeling that neither of you read past the first few lines of the report (I’m very careful to research and test thoroughly before I post in the support category, and I always try to include detailed repro steps).

The thing is, in my experience, when support request receives a response like this—assuming a user error without trying to actually repro the issue using the provided steps (especially from such experienced members as yourselves)—the real issue is less likely to be picked up by the Discourse team.

On the other hand, if your response would either validate or invalidate the actual repro steps, this would lend weight to the claim (or point to some other cause) which will more likely attract attention from the team and lead to the eventual fix.

I know that probably 99% of cases are just users failing to read the instructions (I should know, I’ve been there before). But knowing this, we probably shouldn’t make the same mistake trying to answer support issues quickly, rather than thoroughly?

5

I am a surprised and TBH a bit disappointed to read this. I did read your issue very thoroughly and I had the following observations:

  1. You did in fact not provide complete and detailed repro steps since you did not include the entire command line.

  2. The fact that you only get output when you set a default value for the parameter leads me to believe that Discourse is not seeing your parameter name/value pair.

The conclusion that your command line must be correct because you get output is wrong - and overlooks the fact that you are not getting the output that is associated with the parameter you provided but with its default value.

  1. I did try to - and cannot - reproduce this issue.
curl -X POST "https://REDACTED/admin/plugins/explorer/queries/2/run" -H "Content-Type: multipart/form-data;" -H "Api-Key: REDACTED" -H "Api-Username: system" -F 'params={"group_id":"1"}' {"success":true,"errors":[],"duration":0.3,"result_count":1,"params":{"group_id":"1"},"columns":["id","name"],"default_limit":1000,"relations":{},"colrender":{},"rows":[[1,"admins"]]}

These three observations led me to ask you for a detail in your command line, since I was considering which circumstances would lead to Discourse not seeing the parameter, and I am convinced that this is a syntax issue.

Making a typo or a mistake is not reserved for inexperienced users. I make trivial mistakes every day.

3 Likes
6

Michael (and Jay), please accept my apology, I assumed that you didn’t actually do the repro steps, which I shouldn’t have done! I’ll be more careful not to asume such things in the future.

Hoping you’re still willing to bear with me: I used the exact same curl as you did (I actually copied yours this time, just to be 100% sure), with this result:

{"success":true,"errors":[],"duration":0.2,"result_count":1,"params":{},"columns":["id","name"],"default_limit":1000,"relations":{},"colrender":{},"rows":[[2,"moderators"]]}

and comparing it with yours

{"success":true,"errors":[],"duration":0.3,"result_count":1,"params":{"group_id":"1"},"columns":["id","name"],"default_limit":1000,"relations":{},"colrender":{},"rows":[[1,"admins"]]}

the issue immediately emerges: params":{} vs "params":{"group_id":"1"} in the output, which makes your analysis correct: my server is not seeing/ processing -F 'params={"group_id":"1"}' correctly.

Now that I see the detailed steps of your reasoning it makes perfect sense why you assumed the syntax error (I wish I could read your mind before I posted :blush:). But since I used the exact syntax you did, it cannot be syntax error now, right?

The server is on latest build. What do you think could be the issue?

[Edit]: tried this on another standard standalone install server 2.9.0.beta3 (8040b95e8c) with the same issue. First server is on 2.9.0.beta3 (0f7b9878ff)

Unless this is some weird curl issue I’m at a loss.

curl 7.79.1 (Windows) libcurl/7.79.1 Schannel Release-Date: 2021-09-22 Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp Features: AsynchDNS HSTS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI UnixSockets
2 Likes
7

Windows does not understand those single quotes. So you’ll have to use regular double quotes and escape them with backslashes.

Use this:

-F params={\”group_id\”:\”1\”}

(Don’t copy paste this since iOS messed up the quotes)

3 Likes
8

Well don’t I feel lika a fool now :rofl:

Thanks Michael, you truly own your title! I shall doubt you no more.

4 Likes
9

I did not. If you’re saying that the OP is wrong then my comment is unhelpful. Sorry about that.

Oh, and not I see Michael’s response. Indeed getting quotes and escapes right is a zillion times more difficult than one would think.

2 Likes
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.