Una ejecución de sincronización puede detenerse a medias porque un worker se reinicia, el otro sistema está caído o se rechaza un registro. Tras un worker detenido o una caída pasajera, Tajo retoma la sincronización por sí solo. No vuelve a enviar registros que escribió en los últimos siete días. Esta página explica qué hace, qué ves en la página de la sincronización y los pocos casos en los que tienes que actuar.
Comprobación rápida Abre la sincronización desde Syncs and mappings, en Connections, y lee la ejecución más reciente en Run history. Una ejecución fallida indica qué pasó y qué hacer a continuación.
Qué hace Tajo por sí solo
El cursor. Una ejecución lee su origen por lotes a partir del cursor guardado de la sincronización. El cursor avanza al final de un lote solo cuando llegaron todos los registros de ese lote. Si la ejecución falla, se conserva la última posición que alcanzó sin errores. La siguiente ejecución empieza ahí, así que un lote interrumpido se vuelve a leer en lugar de saltarse.
El registro de entregas. Antes de escribir un registro, este recibe una clave de entrega. La clave es un hash de la sincronización, el origen, el cursor de la página, la posición del registro en la página y el propio registro, así que no contiene datos personales. Antes de llamar al destino, se reclama la clave. Cuando la escritura tiene éxito, la clave se marca como completada y se conserva siete días. La clave no depende de qué ejecución pregunta, así que un reintento o una ejecución programada posterior obtienen la misma clave para el mismo registro. Dentro de esos siete días se usa el resultado guardado y no se vuelve a llamar al destino. Por eso un lote repetido no llega dos veces.
Una ejecución cada vez. Cada sincronización tiene un lease, que la ejecución en curso mantiene durante toda su vida. El lease tiene su propio token y una vida de 15 minutos, y se renueva cada 5 minutos mientras la ejecución trabaja. Una ejecución que pierde su lease se detiene antes de su siguiente escritura o punto de control, para no escribir dos veces. Cuando un worker se detiene, su lease deja de renovarse y vence en un máximo de 15 minutos.
Reintentos automáticos. Una ejecución en cola que falla tiene hasta cinco intentos. Tajo espera 60 segundos antes del segundo intento, y luego 120, 240 y 480 segundos. Un reintento o una ejecución de prueba que lanzas tú se ejecuta una sola vez. No se reintenta una ejecución que chocó con otra ya en curso, ni una cuya versión publicada o cuyas conexiones ya no son válidas.
Ejecuciones atascadas. En una sincronización que Tajo ejecuta según una programación, una ejecución se cierra y se pone otra en cola cuando empezó hace más de una hora y ya no tiene su lease. La ejecución cerrada muestra “The run stopped reporting progress and was closed.” Así, el lease de una ejecución detenida dura como mucho 15 minutos, y la ejecución atascada de una sincronización programada se sustituye al cabo de una hora. Entender la sincronización de datos de Shopify con Brevo indica qué sincronizaciones se ejecutan según una programación.
Pausa tras fallos repetidos. Si las últimas cinco ejecuciones terminadas desde el último cambio de la sincronización fallaron todas, Tajo pausa la sincronización. Su página muestra “Paused automatically by the failure circuit breaker” con el último error. Una ejecución correcta pone el recuento a cero. Nada reinicia por sí solo una sincronización pausada: sigue en pausa hasta que corriges la causa y la vuelves a publicar.
La comprobación horaria. Cada hora, a y 13, Tajo avisa a su propio equipo de cualquier espacio de trabajo con una sincronización activa y sin ninguna ejecución correcta en las últimas 24 horas. Eso incluye un espacio de trabajo en el que no se registró ninguna ejecución. La alerta salta una vez, y solo vuelve a saltar después de que una ejecución haya terminado bien. Un espacio de trabajo cuya sincronización activa más antigua se activó o se cambió hace menos de 24 horas todavía no se comprueba. Esta alerta llega a Tajo, no a ti, y no cambia tu sincronización.
Qué ves
Abre la sincronización desde Syncs and mappings. Run history muestra cada ejecución con los registros escritos sobre los leídos, el número de fallos, la duración y la hora de inicio. Su estado es Queued, Running, Succeeded, Partial (algunos registros fallaron) o Failed.
- Una ejecución en marcha que no ha informado de su progreso en 2 minutos muestra “Waiting for a fresh progress update”.
- Una ejecución fallida muestra una frase sobre qué pasó, otra sobre qué hacer a continuación, el nombre del fallo y el id de la ejecución.
- View DLQ, en la página Syncs, muestra las ejecuciones fallidas y parciales de todas las sincronizaciones, cada una con un botón Retry.
Qué hacer
- Lee la ejecución fallida más reciente. Su línea “qué hacer” es el siguiente paso. La tabla de abajo recoge los fallos que más probablemente verás.
- Si dice “Nothing”, espera. La siguiente ejecución programada se recupera sola.
- Si dice que vuelvas a ejecutar la sincronización, pulsa Retry en la ejecución fallida, en View DLQ. El reintento empieza desde el cursor guardado, así que los lotes ya escritos no se vuelven a escribir. Un reintento correcto quita la ejecución fallida de la lista.
- Si la sincronización se pausó, corrige la causa que indica el aviso y vuelve a publicar la sincronización con Publish sync o Request publish approval.
- Si vuelve el mismo fallo, envíanos el id de la ejecución que aparece bajo la ejecución fallida.
Cada nombre de fallo corresponde a una frase sobre qué pasó, otra sobre qué hacer a continuación y a quién le toca corregirlo: a ti o a Tajo.
| Nombre del fallo | Qué pasó | Qué hacer | Quién lo corrige |
|---|---|---|---|
lease_conflict | Ya había otra ejecución de esta sincronización en curso. | Nada. La ejecución en curso terminará; la siguiente ejecución programada empieza con normalidad. | Tajo |
lease_lost | La ejecución perdió su turno a mitad de camino y se detuvo para no escribir dos veces. | Vuelve a ejecutar la sincronización. | Tajo |
lease_unavailable | La sincronización no pudo reservar su turno de ejecución. | Vuelve a ejecutar la sincronización. Si falla de la misma forma, envíanos el id de la ejecución. | Tajo |
stale_job_swept | La ejecución dejó de informar de su progreso y se cerró. | Vuelve a ejecutar la sincronización. | Tajo |
provider_rate_limited | El otro sistema nos pidió que fuéramos más despacio. | Nada. Espera a la siguiente ejecución programada. | Tajo |
provider_unavailable | El otro sistema no estaba disponible o no respondió a tiempo. | Nada. Espera a la siguiente ejecución programada. Si falla de la misma forma durante un día, envíanos el id de la ejecución. | Tajo |
connection_missing | Una herramienta que usa la sincronización no está conectada en este espacio de trabajo; la ejecución indica cuál. | Conéctala y vuelve a ejecutar la sincronización. | Tú |
connection_unauthorized | El otro sistema rechazó nuestro acceso. | Reconecta la conexión para que obtenga una autorización nueva y vuelve a ejecutar la sincronización. | Tú |
destination_rejected | El destino rechazó todos los registros de esta ejecución. | Comprueba la asignación de campos frente a los campos obligatorios y los formatos del destino, y vuelve a ejecutar la sincronización. | Tú |
node_failed | Un paso de la sincronización falló al leer, transformar o escribir registros. | Abre la ejecución para ver qué paso falló y por qué, corrígelo y vuelve a ejecutar la sincronización. | Tú |
attestation_rule_not_active | Esta sincronización está en pausa. | Reanuda la sincronización para ejecutarla. | Tú |
attestation_publication_not_attested | Esta versión de la sincronización no se ha publicado. | Publica la sincronización. Los cambios en una sincronización no se ejecutan hasta que se publican. | Tú |
unclassified_exception | La sincronización falló por un motivo que aún no hemos clasificado. | Vuelve a ejecutar la sincronización. Si falla de la misma forma, envíanos el id de la ejecución. | Tajo |
Qué puede salir mal
- Retry responde “This sync rule is already running.” Un reintento o una ejecución de prueba que lanzas se rechaza mientras alguna ejecución de la sincronización aparezca como Queued o Running, incluida una cuyo worker se detuvo. En una sincronización que Tajo ejecuta según una programación, esa ejecución se cierra y se sustituye cuando empezó hace más de una hora. Para cualquier otra sincronización, envíanos el id de la ejecución.
- Una sincronización lleva más de siete días fallando. Pasados siete días, el registro de entregas olvida una escritura completada. Un lote repetido después de ese plazo puede volver a escribir registros, así que revisa el destino por si hay contactos duplicados.
- Una sincronización está callada mientras otra funciona. La comprobación horaria vigila el espacio de trabajo, no cada sincronización. Una sincronización sana oculta a otra callada en el mismo espacio de trabajo, así que lee el Run history de cada sincronización.
- Quieres otros límites. La pausa tras cinco fallos y la comprobación de 24 horas se fijan para toda la instalación de Tajo, no por sincronización.