Supervisar, repetir y recuperar una ejecución

Distinga estado, resultado y recuperación en Monitor antes de repetir tareas con posibles efectos sobre los datos.

Localizar el intento correcto

Abra Monitor y ajuste período, tipo de objeto, estado y worker cuando corresponda. Busque el identificador del intento, no únicamente el nombre del Workflow: un mismo objeto puede tener varias ejecuciones. Los filtros de período cambian lo que ve; no garantizan retención ilimitada.

Abra el detalle para revisar tareas, tiempos, versiones, parámetros autorizados y los eventos o logs disponibles. Una aceptación en cola no significa que el worker haya empezado; un estado succeeded tampoco sustituye la comprobación del resultado de negocio.

Elegir la acción según el estado

Acción	Cuándo aparece y qué revisar
Open definition	Abre la definición asociada. Compare la versión del intento con cualquier borrador abierto.
`Download output`	Para una ejecución de `Mapping` o `Session` satisfactoria con salida disponible y acceso permitido. Un `Workflow` agrupa tareas; puede necesitar abrir su tarea `Session`.
Re-run	Para intentos succeeded, failed, cancelled o terminated. Empieza desde el principio usando la definición fijada y la entrada correspondiente.
Recover	Para intentos failed, cancelled o terminated con contexto de recuperación válido. Retoma tareas a partir del punto de recuperación disponible.
Cancel	Para trabajo queued que todavía espera ejecución.
Terminate	Para una ejecución activa. Revise después el estado final y cualquier efecto ya producido.

Las opciones disponibles también dependen de su autorización y del contexto. No interprete un botón ausente como permiso para recrear la operación por otra vía.

Investigar un fallo antes de reintentar

Abra el intento y localice la primera tarea que falló o quedó esperando.
Revise su error concreto, definición y versión, parámetros efectivos, worker y acceso a entradas o Connections.
Compruebe si el destino recibió datos, aunque el intento global haya fallado.
Corrija la causa en la configuración correspondiente y determine si requiere publicar una versión nueva o completar una entrada.
Decida entre Re-run y Recover según qué partes debe ejecutar otra vez y el contexto disponible.
Identifique el intento resultante y compruebe tareas, esquema, filas y reglas de negocio. Conserve la relación con el intento anterior.

Ejemplo de una salida que ya existe

Una Session escribe un CSV y una tarea posterior falla. Si repite todo el Workflow con la misma ruta, puede sobrescribir o duplicar resultados según el destino. Para el laboratorio, utilice una salida independiente y compruebe sus tres filas antes de comparar. Para una base de datos con append, revise las claves y la política de repetición antes de iniciar otra escritura.

Recover no es una transacción distribuida. El punto de recuperación y los commits previos determinan qué trabajo queda persistido. Incluso una operación terminada puede haber confirmado lotes antes de recibir la orden. Los archivos y servicios externos también pueden haber cambiado desde el primer intento.

Criterios de recuperación aceptada

El nuevo intento tiene un identificador y una relación de recuperación o repetición explicable.
Las tareas ejecutadas, omitidas y reutilizadas corresponden a la acción elegida.
La salida cumple columnas, conteo, claves y valores esperados, sin duplicados no previstos.
Los estados de worker, tarea e intento son coherentes y no queda una operación desconocida en curso.

Esperas y evidencia insuficiente

Ante una espera, revise padres y condiciones, políticas de concurrencia, recursos y slots del worker. Si faltan logs o salida, compruebe filtros, permisos y evidencia retenida; no invente una conclusión a partir de un panel vacío. Evite purgar el historial que necesita para investigar. Para solicitar ayuda, use el formulario de Cloudata con versión 22.0.5, identificador del intento y un ejemplo sintético, sin claves ni datos de clientes.