`DataExplorer::ValidationError : paramètre manquant` lors de l'exécution de requêtes Data Explorer avec [params] via l'API

Il y a un bug dans l’API Discourse lors de l’exécution de requêtes Data Explorer contenant des paramètres (les deux requêtes ci-dessous fonctionnent comme prévu lorsqu’elles sont exécutées depuis le navigateur).

En suivant les instructions de Run Data Explorer queries with the Discourse API et en utilisant

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

pour exécuter cette requête (qui a un paramètre sans valeur par défaut définie)

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

entraîne une erreur : {\"success\":false,\"errors\":[\"DataExplorer::ValidationError: Missing parameter group_id of type int\"]}

Lorsqu’une requête a un paramètre avec sa valeur par défaut définie, l’appel API réussit, mais le résultat est le même quelle que soit la valeur fournie via -F 'params=

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

et il renvoie toujours le résultat pour la valeur par défaut du paramètre : {\"success\":true,\"errors\":[],\"duration\":0.2,\"result_count\":1,\"params\":{},\"columns\":[\"id\",\"name\"],\"default_limit\":1000,\"relations\":{},\"colrender\":{},\"rows\":[[2,\"moderators\"]]}

Quelle est la commande complète que vous utilisez ?
Fournissez-vous -X POST et tous les en-têtes requis ?

Le navigateur utilise l’API. Il est improbable que vous décriviez un grand « if » dans le discours.

Celle de Comment exécuter des requêtes Data Explorer avec l’API Discourse complète avec -X POST et tous les en-têtes requis.

Ce n’est pas un problème de syntaxe, si vous vérifiez la dernière ligne de l’OP, vous verrez que curl renvoie un succès, c’est juste que le résultat est incorrect.

Jay, je ne comprends pas le sens de cette phrase. Avez-vous par hasard essayé de reproduire le problème en utilisant les exemples minimaux fournis dans l’OP ?


@michaeld, @pfaffman
J’hésite à écrire cette partie, principalement parce que j’admire et respecte votre dévouement et votre expertise à fournir un support gratuit à la communauté, j’ai bénéficié de vos éclairages à de nombreuses reprises auparavant. Mais cette fois, j’ai l’impression qu’aucun de vous n’a lu au-delà des premières lignes du rapport (je fais très attention à rechercher et tester minutieusement avant de poster dans la catégorie support, et j’essaie toujours d’inclure des étapes de reproduction détaillées).

Le fait est que, d’après mon expérience, lorsqu’une demande de support reçoit une réponse comme celle-ci — en supposant une erreur utilisateur sans essayer de reproduire le problème en utilisant les étapes fournies (surtout de la part de membres aussi expérimentés que vous) — le vrai problème est moins susceptible d’être pris en charge par l’équipe Discourse.

D’un autre côté, si votre réponse validait ou invalidait les étapes de reproduction réelles, cela donnerait du poids à la réclamation (ou indiquerait une autre cause) ce qui attirera plus probablement l’attention de l’équipe et conduira à la correction éventuelle.

Je sais que probablement 99% des cas sont simplement des utilisateurs qui ne lisent pas les instructions (je devrais savoir, j’en ai fait l’expérience auparavant). Mais sachant cela, ne devrions-nous pas faire la même erreur en essayant de répondre rapidement aux problèmes de support, plutôt que de manière approfondie ?

Je suis surpris et, franchement, un peu déçu de lire cela. J’ai lu votre problème très attentivement et j’ai fait les observations suivantes :

  1. Vous n’avez pas fourni d’étapes de reproduction complètes et détaillées, car vous n’avez pas inclus la ligne de commande entière.

  2. Le fait que vous n’obteniez un résultat que lorsque vous définissez une valeur par défaut pour le paramètre me fait croire que Discourse ne voit pas votre paire nom/valeur de paramètre.

La conclusion selon laquelle votre ligne de commande doit être correcte parce que vous obtenez un résultat est erronée - et néglige le fait que vous n’obtenez pas le résultat associé au paramètre que vous avez fourni, mais celui de sa valeur par défaut.

  1. J’ai essayé - et je ne peux pas - reproduire ce problème.
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"]]}

Ces trois observations m’ont amené à vous demander un détail dans votre ligne de commande, car j’envisageais les circonstances qui pourraient amener Discourse à ne pas voir le paramètre, et je suis convaincu qu’il s’agit d’un problème de syntaxe.

Faire une faute de frappe ou une erreur n’est pas réservé aux utilisateurs inexpérimentés. Je fais des erreurs triviales tous les jours.

3 « J'aime »

Michael (et Jay), veuillez accepter mes excuses, j’ai supposé que vous n’aviez pas réellement effectué les étapes de reproduction, ce que je n’aurais pas dû faire ! Je ferai plus attention à ne pas supposer de telles choses à l’avenir.

En espérant que vous êtes toujours prêt à me supporter : j’ai utilisé exactement le même curl que vous (je l’ai copié cette fois, juste pour être sûr à 100%), avec ce résultat :

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

et en le comparant au vôtre

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

le problème apparaît immédiatement : params\":{} contre \"params\":{\"group_id\":\"1\"} dans la sortie, ce qui rend votre analyse correcte : mon serveur ne voit/traite pas correctement -F 'params={\"group_id\":\"1\"}'.

Maintenant que je vois les étapes détaillées de votre raisonnement, il est tout à fait logique que vous ayez supposé une erreur de syntaxe (j’aimerais pouvoir lire dans vos pensées avant que je ne poste :blush:). Mais puisque j’ai utilisé la syntaxe exacte que vous avez utilisée, il ne peut plus s’agir d’une erreur de syntaxe maintenant, n’est-ce pas ?

Le serveur est sur la dernière version. Quelle pourrait être la cause du problème selon vous ?

[Edit] : J’ai essayé cela sur un autre serveur d’installation autonome standard 2.9.0.beta3 (8040b95e8c) avec le même problème. Le premier serveur est sur 2.9.0.beta3 (0f7b9878ff)

À moins qu’il ne s’agisse d’un étrange problème de curl, je suis perdu.

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 « J'aime »

Windows ne comprend pas ces apostrophes. Vous devrez donc utiliser des guillemets doubles classiques et les échapper avec des barres obliques inverses.

Utilisez ceci :

-F params={"group_id":"1"}

(Ne copiez pas-collez ceci car iOS a mal géré les guillemets)

3 « J'aime »

Je me sens tellement idiot maintenant :rofl:

Merci Michael, tu es vraiment à la hauteur de ton titre ! Je ne douterai plus jamais de toi.

4 « J'aime »

Je ne l’ai pas fait. Si vous dites que le message d’origine est erroné, alors mon commentaire est inutile. Désolé pour cela.

Oh, et maintenant je vois la réponse de Michael. En effet, obtenir les citations et les échappements correctement est un million de fois plus difficile qu’on ne le pense.

2 « J'aime »

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