Ir al contenido

MergeMultiple

El modulo mergeMultiple es un nodo de convergencia que espera y combina datos de múltiples ramas paralelas del workflow. Cuando un flujo se divide en varias ramas (por ejemplo, mediante un Decision o Switch), mergeMultiple espera a que todas las ramas predecesoras hayan completado su ejecución antes de continuar. Utiliza la base de datos (tabla merge_states) para almacenar los datos parciales de cada rama y verificar cuando se han recibido todos. Soporta iteraciones anidadas con claves de merge unicas por nivel y grupo. Incluye un mecanismo de timeout configurable (5 minutos por defecto) para evitar bloqueos si una rama nunca llega, y protección contra re-ejecuciones fantasma.

ParámetroTipoRequeridoDescripción
(sin parámetros configurables por el usuario)--Este modulo se configura automáticamente basandose en las conexiones del workflow. Los modulos predecesores se detectan automáticamente.
{
"nextModule": "siguiente_modulo",
"iterationInfo": { "current": 2, "total": 2 },
"data": {
"merged": {
"rama_A": { "datos": "de rama A" },
"rama_B": { "datos": "de rama B" }
},
"array": [
{ "source": "rama_A", "data": { "datos": "de rama A" } },
{ "source": "rama_B", "data": { "datos": "de rama B" } }
],
"items": [],
"sources": ["rama_A", "rama_B"],
"missingSources": [],
"count": 2,
"totalItems": 0,
"status": "complete",
"timedOut": false
}
}

El campo iterationInfo siempre se incluye en la respuesta (tanto al completar como en estado pendiente) y refleja cuantos grupos de merge se recibieron vs. cuantos se esperan — no el índice del item del batch que disparo la llamada. Esto es lo que muestra el badge de progreso en el canvas.

Respuesta en estado pendiente (aun esperando ramas):

{
"nextModule": null,
"iterationInfo": { "current": 1, "total": 2 },
"data": {
"status": "pending",
"received": ["mergeResults_5"],
"expected": ["mergeResults_5", "mergeResults_10"],
"missing": ["mergeResults_10"],
"progress": "1/2"
}
}
{
"label": "mergeMultiple"
}
  • Los modulos predecesores se detectan automáticamente a partir de las conexiones del workflow, o se pueden especificar manualmente via config.predecessors.
  • Los datos de cada rama se almacenan en la tabla merge_states de la base de datos.
  • La clave única de merge se construye como: {workflowId}_{moduleName}_{mergeGroupKey}_{mergeLevel}.
  • Timeout configurable con config.mergeTimeout (en milisegundos). Por defecto: 300000ms (5 minutos). Si expira, continua con los datos disponibles y marca timedOut: true.
  • Cuando el nodo Decision salta una rama, automáticamente inserta un registro “skipped” para desbloquear este merge.
  • Protección contra re-ejecuciones fantasma: si el merge ya se completo para la misma clave, ignora la ejecución duplicada.
  • La salida incluye múltiples formatos: merged (objeto por source), array (array de objetos), items (items unificados de todas las ramas).
  • Crea automáticamente la tabla merge_states si no existe.
  • Si faltan predecesores, retorna el status pending con la lista de modulos faltantes y el progreso.
  • Seguimiento de fuente en ejecución por lotes: cuando es llamado desde la cadena de batch de un Iterator, el motor identifica automáticamente que modulo predecesor (mergeResults_5, mergeResults_10, etc.) envío los datos. Esto permite a mergeMultiple rastrear correctamente que ramas han llegado aunque múltiples batches de Iterator corran de forma concurrente.
  • Merge entre ejecuciones con Delay/Wait: como la clave de merge esta basada en workflowId (que es reutilizado por ejecuciones reanudadas después de un delay), un nodo mergeMultiple puede recolectar entradas de ramas que corrieron en distintas fases de ejecución — por ejemplo, una rama antes del Delay y otra después de que el Delay se reactiva.
  • Badge de progreso en el canvas: el nodo muestra N/M donde N = grupos recibidos y M = total de grupos esperados (ej. 2/2), no el índice del item del batch que lo disparo.