`DataExplorer::ValidationError: Parámetro faltante` al ejecutar consultas de Data Explorer con [params] a través de la API

Hay un error en la API de Discourse al ejecutar consultas del Explorador de Datos que contienen parámetros (ambas consultas a continuación funcionan como se esperaba cuando se ejecutan desde el navegador).

Siguiendo las instrucciones de Run Data Explorer queries with the Discourse API y usando

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

para ejecutar esta consulta (que tiene un parámetro sin su valor predeterminado establecido)

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

genera un error: {"success":false,"errors":["DataExplorer::ValidationError: Missing parameter group_id of type int"]}

Cuando una consulta tiene un parámetro con su valor predeterminado establecido, la llamada a la API es exitosa, pero el resultado es el mismo independientemente del valor proporcionado a través de -F 'params=

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

y siempre devuelve el resultado del valor predeterminado del parámetro: {"success":true,"errors":[],"duration":0.2,"result_count":1,"params":{},"columns":["id","name"],"default_limit":1000,"relations":{},"colrender":{},"rows":[[2,"moderators"]]}

¿Cuál es el comando completo que estás usando?
¿Estás proporcionando -X POST y todas las cabeceras requeridas?

El navegador utiliza la API. Es improbable que estés describiendo un gran “if” en Discourse.

El del Cómo ejecutar consultas de Data Explorer con la API de Discourse completo con -X POST y todas las cabeceras requeridas.

Esto no es un problema de sintaxis, si revisas la última línea del OP verás que curl devuelve un éxito, es solo que el resultado es incorrecto.

Jay, no entiendo el significado de esta frase. ¿Intentaste reproducir el problema utilizando los ejemplos mínimos proporcionados en el OP?


@michaeld, @pfaffman
Dudo en escribir esta parte, principalmente porque admiro y respeto su dedicación y experiencia para brindar soporte gratuito a la comunidad, sé que me he beneficiado de sus ideas en numerosas ocasiones anteriores. Pero esta vez tengo la sensación de que ninguno de los dos leyó más allá de las primeras líneas del informe (soy muy cuidadoso en investigar y probar a fondo antes de publicar en la categoría de soporte, y siempre intento incluir pasos de reproducción detallados).

La cuestión es que, en mi experiencia, cuando una solicitud de soporte recibe una respuesta como esta —asumiendo un error del usuario sin intentar reproducir el problema utilizando los pasos proporcionados (especialmente de miembros tan experimentados como ustedes)—, es menos probable que el equipo de Discourse detecte el problema real.

Por otro lado, si su respuesta validara o invalidara los pasos de reproducción reales, esto daría peso a la afirmación (o señalaría alguna otra causa) que probablemente atraerá la atención del equipo y conducirá a la solución final.

Sé que probablemente el 99% de los casos son simplemente usuarios que no leen las instrucciones (debería saberlo, ya he pasado por eso). Pero sabiendo esto, ¿probablemente no deberíamos cometer el mismo error al intentar responder a los problemas de soporte rápidamente, en lugar de hacerlo a fondo?

Me sorprende y, sinceramente, me decepciona un poco leer esto. Leí tu problema a fondo y tuve las siguientes observaciones:

  1. De hecho, no proporcionaste pasos de reproducción completos y detallados, ya que no incluiste la línea de comandos completa.

  2. El hecho de que solo obtengas una salida cuando estableces un valor predeterminado para el parámetro me lleva a creer que Discourse no está viendo tu par nombre/valor de parámetro.

La conclusión de que tu línea de comandos debe ser correcta porque obtienes una salida es errónea, y pasa por alto el hecho de que no estás obteniendo la salida asociada con el parámetro que proporcionaste, sino con su valor predeterminado.

  1. Intenté - y no puedo - reproducir este problema.
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"]]}

Estas tres observaciones me llevaron a pedirte un detalle en tu línea de comandos, ya que estaba considerando qué circunstancias llevarían a que Discourse no viera el parámetro, y estoy convencido de que este es un problema de sintaxis.

Cometer un error tipográfico o un desliz no es algo exclusivo de los usuarios inexpertos. Yo cometo errores triviales todos los días.

3 Me gusta

Michael (y Jay), por favor, acepten mis disculpas, asumí que en realidad no hicieron los pasos de repro, ¡lo cual no debería haber hecho! Seré más cuidadoso de no asumir tales cosas en el futuro.

Con la esperanza de que todavía estén dispuestos a tenerme paciencia: usé el mismo curl que ustedes (de hecho, copié el suyo esta vez, solo para estar 100% seguro), con este resultado:

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

y comparándolo con el suyo

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

el problema surge inmediatamente: params":{} vs "params":{"group_id":"1"} en la salida, lo que hace que su análisis sea correcto: mi servidor no ve/procesa correctamente -F 'params={\"group_id\":\"1\"}'.

Ahora que veo los pasos detallados de su razonamiento, tiene perfecto sentido por qué asumió el error de sintaxis (ojalá pudiera leer su mente antes de publicar :blush:). Pero como usé la misma sintaxis que usted, no puede ser un error de sintaxis ahora, ¿verdad?

El servidor está en la última compilación. ¿Qué cree que podría ser el problema?

[Edit]: probé esto en otro servidor de instalación independiente estándar 2.9.0.beta3 (8040b95e8c) con el mismo problema. El primer servidor está en 2.9.0.beta3 (0f7b9878ff)

A menos que este sea algún problema extraño de curl, estoy perdido.

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 Me gusta

Windows no entiende esas comillas simples. Así que tendrás que usar comillas dobles normales y escaparlas con barras invertidas.

Usa esto:

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

(No copies y pegues esto ya que iOS estropeó las comillas)

3 Me gusta

Ahora me siento como un tonto :rofl:

Gracias Michael, ¡realmente haces honor a tu título! Ya no dudaré de ti.

4 Me gusta

No lo hice. Si estás diciendo que el OP está mal, entonces mi comentario no es útil. Lo siento.

Oh, y ahora veo la respuesta de Michael. De hecho, conseguir las citas y los escapes correctamente es un millón de veces más difícil de lo que uno pensaría.

2 Me gusta

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