Cola de mensajes fallidos en n8n: un ejercicio de reenvío selectivo
Ejercicio editorial de cola de mensajes fallidos en n8n: conserva registros, reenvía un payload corregido a WireMock y comprueba el número de peticiones.
Comprobado con las fuentes citadas el .
Ejercicio editorial: tarea y límites
Construye una cola de mensajes fallidos en n8n que almacene registros sintéticos fallidos con sus motivos e identificadores de correlación y, después, reenvía manualmente solo un registro corregido. Compara los recuentos de peticiones de WireMock para comprobar que los registros que ya se procesaron correctamente y los no seleccionados no reciben peticiones adicionales. Este es un ejercicio editorial; su implementación y los resultados esperados no se han ejecutado ni validado aquí.
Necesitas un entorno n8n con Data Tables, conocimientos básicos de REST y un servidor WireMock proporcionado por quien facilita el ejercicio y accesible desde n8n. Data Tables permite mantener datos entre workflows del mismo proyecto y realizar operaciones condicionales sobre las filas. Es adecuado para un almacenamiento ligero o moderado, tiene límites de almacenamiento por instancia y, de forma predeterminada, es accesible para los miembros del proyecto.
Mantén el procesamiento manual y secuencial: desactiva los reintentos automáticos de peticiones y no permitas la edición simultánea de tablas. Los cambios simultáneos pueden provocar inconsistencias en las lecturas paginadas de Data Tables. La recuperación concurrente, el reenvío automático, el despliegue en producción y las garantías de procesamiento exactamente una vez quedan fuera del alcance. Creemos que un ejercicio de recuperación deliberadamente acotado resulta más útil que un diseño con apariencia de producción cuyas garantías no están claras.
Sources: n8n-docs/docs/build/work-with-data/data-tables.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub, Running as a Standalone Process | WireMock
Prepara los registros y el servidor simulado determinista
Utiliza los siguientes datos de prueba creados para el ejercicio, con peticiones POST y cuerpos JSON. Establece X-Correlation-ID con el ID del registro. Pide a quien facilita el ejercicio que configure coincidencias exactas del cuerpo JSON para estas respuestas, además de una respuesta predeterminada de 400 con {"reason":"fixture mismatch"}. Estos son datos de entrada y respuestas esperadas creados para el ejercicio.
| Registro / cabecera | Ruta | Cuerpo inicial | Respuesta inicial | Cuerpo corregido / respuesta |
|---|---|---|---|---|
| A | /orders/A | {"quantity":1} | 201; {"accepted":true} | Sin corrección |
| B | /orders/B | {"quantity":0} | 422; {"reason":"quantity must be positive"} | {"quantity":2}; 201; {"accepted":true} |
| C | /orders/C | {"quantity":3} | 503; {"reason":"simulated outage"} | Sin corrección |
WireMock permite establecer coincidencias de cabeceras y cuerpos. n8n admite cabeceras personalizadas y cuerpos JSON, aunque la fuente de configuración proporcionada es el código de HTTP Request V3 en master, en lugar de una versión fijada. En este ejercicio, la cabecera de correlación identifica las peticiones para contarlas; no implementa idempotencia.
Sources: n8n/packages/nodes-base/nodes/HttpRequest/V3/Description.ts at master · n8n-io/n8n · GitHub, Request Matching | WireMock
Captura los fallos en tu cola de mensajes fallidos de n8n
Para esta cola de mensajes fallidos de n8n, crea una Data Table llamada failures con los campos correlationId, path, originalPayloadJson, replayPayloadJson, failureReason, httpStatus, status y replayOutcome. Mantén una tabla outcomes independiente para los resultados iniciales, incluidos los correctos. Estos campos constituyen un esquema editorial; las operaciones condicionales de inserción, consulta y actualización son capacidades documentadas, no garantías de reenvío transaccional.
Construye el workflow de captura en este orden. Inspecciona las salidas reales de los nodos antes de escribir expresiones: no está garantizado que una rama de error conserve el payload de negocio original.
- Conserva el ID, la ruta y el JSON original de cada registro antes de HTTP Request.
- Envía la petición de prueba con Include Response Headers and Status activado y Never Error desactivado.
- Configura On Error como Continue (using error output) y conecta explícitamente esa salida.
- Inspecciona ambas salidas: clasifica las respuestas correctas en la rama normal y los fallos HTTP 422 y 503 del ejercicio en la rama de error.
- Asigna los campos de estado HTTP y motivo que estén realmente disponibles, recuperando el ID y el payload conservados mediante una vinculación válida de elementos. Detén el proceso si no puedes recuperar el estado, el motivo o el payload original de una respuesta de prueba; no adivines las rutas de los campos.
- Gestiona los errores de transporte por separado, ya que pueden carecer de respuesta HTTP. Registra todos los resultados iniciales; inserta los fallos con status failed, sus payloads y un motivo no vacío.
Para las entradas vinculadas, n8n documenta $('Preserve input').item.json cuando ese nombre de nodo y la vinculación de elementos son válidos. La vinculación con una sola entrada y una sola salida permite el diseño secuencial de este ejercicio, pero los elementos nuevos o los cambios en su cantidad pueden romper el vínculo. Nosotros detendríamos el proceso si faltara un payload, en lugar de sustituirlo por el primer elemento de un lote mixto.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub, HTTP Request | Nodes | n8n Docs, n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/reference-data/reference-previous-nodes.md at main · n8n-io/n8n-docs · GitHub, How items link through workflows | Build | n8n Docs
Corrige B y reenvía solo las filas que cumplan las condiciones
Inspecciona el motivo almacenado y el payload original de B. Establece replayPayloadJson en {"quantity":2}, conservando originalPayloadJson sin cambios. Deja C sin seleccionar. Antes del reenvío, guarda los recuentos de peticiones de A, B y C mediante POST /__admin/requests/count con cuerpos como {"method":"POST","urlPath":"/orders/A","headers":{"X-Correlation-ID":{"equalTo":"A"}}}; sustituye A por B y C de forma coherente.
Construye un workflow manual independiente que recupere únicamente correlationId B con status failed. Envía su payload corregido a la ruta almacenada con la misma cabecera. Mantén Include Response Headers and Status activado, deja Never Error desactivado, desactiva los reintentos automáticos y conecta Continue (using error output) a un gestor de fallos. Inspecciona ambas salidas y asigna sus campos reales de estado y motivo, como en la captura. Solo después de inspeccionar una respuesta 201 confirmada, actualiza esa fila a status replayed y registra el resultado. Si falla, conserva el motivo y mantén la fila disponible para su inspección.
Ejecuta la misma selección de nuevo después del éxito: no debería devolver ninguna fila B que cumpla las condiciones ni enviar ninguna petición. En nuestra opinión, las condiciones de selección deben formar parte de la consulta, donde quien revise el workflow pueda inspeccionarlas antes de cualquier llamada al destino.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/HttpRequest/V3/Description.ts at master · n8n-io/n8n · GitHub, HTTP Request | Nodes | n8n Docs, n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, Request Matching | WireMock, Verifying | WireMock
Verifica los recuentos de peticiones y reflexiona sobre la incertidumbre
Repite exactamente las mismas consultas de recuento y compara los resultados con los valores de referencia guardados. La verificación de WireMock depende de su registro de peticiones en memoria: los reinicios de ese registro, su desactivación o la eliminación de entradas invalidan la comparación.
Guarda también un recuento del cuerpo corregido antes del reenvío enviando por POST {"method":"POST","urlPath":"/orders/B","headers":{"X-Correlation-ID":{"equalTo":"B"}},"bodyPatterns":[{"equalToJson":{"quantity":2}}]} a /__admin/requests/count en tu servidor WireMock. Repítelo después del reenvío: el incremento esperado es de uno y, después, de cero al seleccionar B una vez reenviado. Conserva también la consulta más amplia de B para que sigan siendo visibles las peticiones adicionales con cualquier payload.
Contrasta cada estado y motivo de respuesta registrado con los datos de prueba: A inicial debería tener 201; B inicial, 422 con quantity must be positive; C inicial, 503 con simulated outage; y B corregido, 201. Considera una comprobación fallida cualquier respuesta 400 con fixture mismatch, la ausencia de un motivo o una respuesta inesperada. Utiliza las siguientes comprobaciones esperadas como criterios de finalización.
Si falla alguna comprobación, inspecciona las reglas de coincidencia del servidor simulado, las ramas de captura y la vinculación de payloads antes de continuar. Reflexiona sobre esta pregunta: ¿qué ocurre si el destino acepta B pero falla el registro del éxito? Este ejercicio de cola de mensajes fallidos en n8n muestra el encaminamiento selectivo de peticiones bajo las restricciones indicadas; la recuperación en producción también requiere una gestión de los resultados inciertos específica para cada destino, una persona responsable de la recuperación y una política de retención.
Sources: n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/reference-data/reference-previous-nodes.md at main · n8n-io/n8n-docs · GitHub, Request Matching | WireMock, Verifying | WireMock
