Ejercicio de GraphQL en n8n: permite una mutación solo con resultados de consulta completos

Por Roman Rodomansky·Publicado el 20 oct 2026

Practica la validación de respuestas GraphQL en n8n, la paginación por cursor y una decisión que bloquee una mutación de prueba si los resultados son incompletos o inválidos.

• Integración de API
• Depuración de flujos de trabajo
• Aprendizaje práctico
• Ejercicio

Comprobado con las fuentes citadas el 20 oct 2026.

Tu ejercicio de GraphQL en n8n

Este ejercicio editorial te propone diseñar un flujo de trabajo de GraphQL en n8n que recopile una conexión completa, compruebe sus registros y permita una única mutación inocua en un entorno de pruebas solo cuando se cumplan todos los requisitos previos. GraphQL.org documenta que las respuestas pueden contener tanto datos como errores, por lo que una respuesta HTTP satisfactoria no basta para determinar si todo está listo. Sus orientaciones sobre HTTP siguen un borrador de especificación, y el comportamiento de los códigos de estado varía según el tipo de medio de la respuesta y la implementación. Inspecciona el cuerpo de la respuesta aunque HTTP indique que la solicitud se ha completado correctamente.

Debes entregar tu flujo de trabajo junto con evidencias de ejecución para los casos sin errores y los casos con fallos deliberados del entorno de pruebas. Se trata de una propuesta de ejercicio de diseño, no de un flujo de trabajo importable ni de una integración ejecutada y validada. La documentación proporcionada no acredita su compatibilidad con todas las versiones o ediciones de n8n.

Creemos que el objetivo de aprendizaje útil es explicar por qué se permitió o bloqueó una escritura, más allá de conseguir que funcione el caso sin errores.

Sources: Serving over HTTP | GraphQL, Response | GraphQL

Prepara un entorno de pruebas controlado y entradas explícitas

Empieza con un entorno n8n existente y un servicio GraphQL de pruebas preparado y accesible. La instalación y el despliegue quedan fuera de este ejercicio. Apollo documenta los resolvers como funciones que rellenan campos del esquema; por tanto, unas respuestas de resolver seleccionadas deliberadamente pueden servir de base para el entorno de pruebas propuesto. El siguiente contrato es una propuesta editorial: pide a la persona responsable del entorno de pruebas que proporcione operaciones de esquema compatibles y casos seleccionables antes de empezar a construir.

Utiliza estas entradas sugeridas. Mantén el flujo de trabajo en modo de solo lectura hasta su rama final de pruebas. Limita la paginación a una sola conexión; las conexiones anidadas, los conjuntos de datos cambiantes, la autorización en producción, los reintentos y la idempotencia de las mutaciones quedan fuera de este ejercicio.

Sources: Resolvers, GraphQL, Pagination | GraphQL

Construye la solicitud de consulta y conserva su respuesta

Para este ejemplo de GraphQL en n8n, utiliza un nodo HTTP Request para enviar un POST con un cuerpo JSON que contenga query y variables. n8n documenta parámetros de paginación en el cuerpo de POST y expresiones para valores dinámicos. Los campos concretos que aparecen a continuación pertenecen al entorno de pruebas propuesto, no a todas las API de GraphQL.

Utiliza el texto de consulta query ReadRecords($first: Int!, $after: String) { records(first: $first, after: $after) { nodes { id name } pageInfo { hasNextPage endCursor } } }. Empieza con first establecido en 2 y after en null dentro de variables. Conserva la respuesta completa, incluidos data y errors.

GraphQL.org distingue los errores de solicitud, que omiten data, de los errores de ejecución, que pueden acompañar a datos parciales. Sus orientaciones para resolver problemas recomiendan inspeccionar el array errors del cuerpo y comprobar la compatibilidad con el esquema. En este ejercicio, registra como fallo cualquier array errors que no esté vacío, aunque haya registros útiles.

Si esperabas utilizar un nodo GraphQL de n8n, mantén este ejercicio centrado en HTTP Request para que la respuesta completa y las variables de continuación permanezcan explícitas.

Sources: Response | GraphQL, n8n-docs/docs/build/code-in-n8n/cookbook/http-request-node/pagination.md at main · n8n-io/n8n-docs · GitHub, Common HTTP Errors and How to Debug Them | GraphQL

Implementa la paginación de GraphQL en n8n conservando los fallos detectados

GraphQL.org presenta los cursores opacos y los metadatos de conexión como un modelo de paginación; el entorno de pruebas debe adoptarlo explícitamente. La documentación de GraphQL de GitHub describe cómo continuar con endCursor hasta que hasNextPage pase a false en sus conexiones. Trata los cursores como valores opacos, no como números de página.

n8n documenta valores de paginación derivados de la respuesta y expresiones de finalización personalizadas, además de bucles explícitos con un nodo IF. Elige aquí el bucle explícito para inspeccionar cada página. Mantén un único elemento de control que contenga el cursor actual, los cursores ya vistos, los registros recopilados, el contador de páginas, el indicador de finalización y los motivos de fallo acumulados. Sigue esta secuencia sugerida.

1. Solicita una página utilizando el cursor actual e incrementa el contador de páginas.
2. Registra los fallos de transporte, los errores del cuerpo de la respuesta y los datos mal formados sin borrar los fallos anteriores.
3. Añade los registros devueltos y conserva sus IDs para compararlos.
4. Marca la recopilación como completa solo cuando un pageInfo válido indique explícitamente hasNextPage=false.
5. Cuando haga falta otra página, rechaza un endCursor ausente o ya visto; en caso contrario, guárdalo y repite el bucle.
6. Utiliza un límite de seguridad sugerido de tres solicitudes; si detiene el recorrido antes de confirmar el final, registra que la recopilación está incompleta.

A nuestro juicio, un fallo debe permanecer registrado durante el resto de la ejecución de este ejercicio; una página posterior sin errores nunca debe borrar un motivo anterior para bloquear la escritura.

Sources: Using pagination in the GraphQL API - GitHub Docs, Pagination | GraphQL, skills/skills/n8n-loops-official/references/HTTP_PAGINATION.md at main · n8n-io/skills · GitHub, n8n-docs/docs/build/flow-logic/loop.md at main · n8n-io/n8n-docs · GitHub

Toma una única decisión sobre si todo está listo y demuestra el resultado

Evalúa un único elemento de control tras el recorrido. La condición de paso sugerida exige una finalización explícita, ningún fallo registrado, campos obligatorios que no estén en blanco y exactamente los IDs esperados, sin duplicados. La documentación de esquemas de Apollo explica que los campos que admiten null pueden devolver null y que las listas no nulas pueden estar vacías; por tanto, la preparación para una operación de negocio necesita sus propias reglas.

Ejemplo editorial con resultados hipotéticos: la primera página devuelve A y B con nombres que no están en blanco, hasNextPage=true y un endCursor opaco. El estado acumulado es records=[A,B], complete=false y failures=[]. Mantén bloqueada la mutación y solicita la segunda página utilizando ese cursor. Supón que la segunda página devuelve C con un nombre que no está en blanco y hasNextPage=false. Sin fallos de transporte ni de GraphQL, el estado acumulado pasa a ser records=[A,B,C], complete=true y failures=[]. Los IDs coinciden exactamente y no hay duplicados, por lo que la única decisión sobre si todo está listo permite una mutación en el entorno de pruebas.

Para una variante hipotética con fallos, supón que alguna de las páginas también contiene un array errors que no está vacío. Conserva ese fallo inmediatamente. Aunque el recorrido devuelva A, B y C con nombres válidos y confirmación del final, failures sigue sin estar vacío y la condición de paso bloquea la mutación.

Dirige esa única decisión hacia una sola mutación en el entorno de pruebas o hacia un resultado bloqueado que enumere los requisitos incumplidos. Envía los IDs recopilados mediante markReviewed y después inspecciona también sus errors y los campos devueltos esperados. Utiliza esta lista de comprobación de aceptación como evidencia que debes aportar.

• Caso sin errores: conserva A, B y C y demuestra que se realiza una sola llamada de mutación.
• Caso con errores parciales: muestra el error conservado y la ausencia de llamadas de mutación.
• Caso con nombre ausente: identifica el registro inválido y bloquea la mutación.
• Caso con cursor repetido: detén el recorrido indicando por qué la recopilación está incompleta.
• Caso de límite de seguridad: bloquea la mutación cuando no se haya confirmado el final.
• Respuesta de la mutación: exige que no haya errores, que accepted=true y que los IDs devueltos coincidan; de lo contrario, informa del fallo.

Reflexión sugerida: explica por qué unos registros parciales válidos y un indicador de página final son insuficientes por separado. La especificación de GraphQL de septiembre de 2025 distingue las consultas de solo lectura de las mutaciones que escriben y recuperan datos; esta condición de paso en el cliente no garantiza que los datos del servidor permanezcan sin cambios entre esas operaciones.

Sources: GraphQL Schema Basics, GraphQL, Common HTTP Errors and How to Debug Them | GraphQL