Une exécution de synchronisation peut s’arrêter à mi-chemin : un worker redémarre, l’autre système est indisponible ou un enregistrement est refusé. Après l’arrêt d’un worker ou une panne passagère, Tajo reprend la synchronisation de lui-même. Il ne renvoie pas les enregistrements écrits au cours des sept derniers jours. Cette page explique ce qu’il fait, ce que vous voyez sur la page de la synchronisation, et les quelques cas où vous devez agir.
Vérification rapide Ouvrez la synchronisation depuis Syncs and mappings, sous Connections, et lisez l’exécution la plus récente dans Run history. Une exécution en échec indique ce qui s’est passé et quoi faire ensuite.
Ce que Tajo fait de lui-même
Le curseur. Une exécution lit sa source par lots, à partir du curseur enregistré de la synchronisation. Le curseur n’avance à la fin d’un lot que si chaque enregistrement de ce lot est arrivé. Si l’exécution échoue, la dernière position atteinte sans erreur est conservée. L’exécution suivante repart de là : un lot interrompu est relu, pas sauté.
Le registre de livraison. Avant d’être écrit, un enregistrement reçoit une clé de livraison. Cette clé est un hash de la synchronisation, de la source, du curseur de page, de la position de l’enregistrement dans la page et de l’enregistrement lui-même. Elle ne contient donc aucune donnée personnelle. Avant l’appel à la destination, la clé est réservée. Quand l’écriture réussit, la clé est marquée comme terminée et conservée sept jours. La clé ne dépend pas de l’exécution qui la demande : une relance ou une exécution planifiée ultérieure obtient la même clé pour le même enregistrement. Pendant ces sept jours, le résultat enregistré est réutilisé et la destination n’est pas rappelée. C’est pourquoi un lot rejoué n’arrive pas deux fois.
Une exécution à la fois. Chaque synchronisation a un seul bail, détenu par l’exécution en cours pendant toute sa durée. Le bail a son propre jeton et une durée de vie de 15 minutes, renouvelée toutes les 5 minutes tant que l’exécution travaille. Une exécution qui perd son bail s’arrête avant sa prochaine écriture ou son prochain point de reprise, pour ne pas écrire deux fois. Quand un worker s’arrête, son bail n’est plus renouvelé et expire en 15 minutes au plus.
Relances automatiques. Une exécution en file d’attente qui échoue a droit à cinq tentatives au plus. Tajo attend 60 secondes avant la deuxième tentative, puis 120, 240 et 480 secondes. Une relance ou une exécution de test que vous lancez vous-même ne s’exécute qu’une fois. Une exécution entrée en conflit avec une exécution déjà en cours n’est pas relancée. Une exécution dont la version publiée ou les connexions ne sont plus valides non plus.
Exécutions bloquées. Pour une synchronisation que Tajo exécute selon un planning, une exécution est fermée et une nouvelle est mise en file d’attente dès qu’elle a démarré il y a plus d’une heure et ne détient plus son bail. L’exécution fermée affiche “The run stopped reporting progress and was closed.” (l’exécution ne signalait plus sa progression et a été fermée). Le bail d’une exécution arrêtée dure donc 15 minutes au plus, et l’exécution bloquée d’une synchronisation planifiée est remplacée au bout d’une heure. Comprendre la synchronisation des données indique quelles synchronisations s’exécutent selon un planning.
Pause après des échecs répétés. Si les cinq dernières exécutions terminées depuis la dernière modification de la synchronisation ont toutes échoué, Tajo met la synchronisation en pause. Sa page affiche “Paused automatically by the failure circuit breaker” (mise en pause automatique par le disjoncteur d’échecs) avec la dernière erreur. Une seule exécution réussie remet le compteur à zéro. Rien ne relance seul une synchronisation en pause : elle le reste jusqu’à ce que vous corrigiez la cause et la publiiez à nouveau.
La vérification horaire. Toutes les heures, à la 13e minute, Tajo alerte sa propre équipe pour tout espace de travail qui a une synchronisation active et aucune exécution réussie au cours des dernières 24 heures. Cela inclut un espace de travail où aucune exécution n’a été enregistrée. L’alerte se déclenche une fois, et ne se déclenche de nouveau qu’après la réussite d’une exécution. Un espace de travail dont la plus ancienne synchronisation active a été activée ou modifiée il y a moins de 24 heures n’est pas encore vérifié. Cette alerte parvient à Tajo, pas à vous, et elle ne modifie pas votre synchronisation.
Ce que vous voyez
Ouvrez la synchronisation depuis Syncs and mappings. Run history liste chaque exécution avec les enregistrements écrits sur les enregistrements lus, le nombre d’échecs, la durée et l’heure de début. Son statut est Queued, Running, Succeeded, Partial (certains enregistrements ont échoué) ou Failed.
- Une exécution en cours qui n’a pas signalé de progression depuis 2 minutes affiche “Waiting for a fresh progress update” (en attente d’une nouvelle mise à jour de la progression).
- Une exécution en échec affiche une phrase sur ce qui s’est passé, une sur quoi faire ensuite, le nom de l’échec et l’identifiant de l’exécution.
- View DLQ, sur la page Syncs, liste les exécutions en échec et partielles de toutes les synchronisations, chacune avec un bouton Retry.
Que faire
- Lisez l’exécution en échec la plus récente. Sa ligne « quoi faire » est l’étape suivante. Le tableau ci-dessous liste les échecs que vous rencontrerez le plus souvent.
- Si elle indique “Nothing”, attendez. La prochaine exécution planifiée se rétablit seule.
- Si elle demande de relancer la synchronisation, appuyez sur Retry pour l’exécution en échec, sous View DLQ. La relance repart du curseur enregistré : les lots déjà écrits ne sont pas réécrits. Une relance réussie retire l’exécution en échec de la liste.
- Si la synchronisation a été mise en pause, corrigez la cause indiquée par la bannière, puis publiez à nouveau la synchronisation avec Publish sync ou Request publish approval.
- Si le même échec revient, envoyez-nous l’identifiant d’exécution affiché sous l’exécution en échec.
Chaque nom d’échec correspond à une phrase sur ce qui s’est passé, une sur quoi faire ensuite, et à qui revient la correction : vous ou Tajo.
| Nom de l’échec | Ce qui s’est passé | Quoi faire | Qui corrige |
|---|---|---|---|
lease_conflict | Une autre exécution de cette synchronisation était déjà en cours. | Rien. L’exécution en cours se terminera ; la prochaine exécution planifiée démarre normalement. | Tajo |
lease_lost | L’exécution a perdu son créneau en cours de route et s’est arrêtée pour ne pas écrire deux fois. | Relancez la synchronisation. | Tajo |
lease_unavailable | La synchronisation n’a pas pu réserver son créneau d’exécution. | Relancez la synchronisation. Si elle échoue de la même façon, envoyez-nous l’identifiant d’exécution. | Tajo |
stale_job_swept | L’exécution ne signalait plus sa progression et a été fermée. | Relancez la synchronisation. | Tajo |
provider_rate_limited | L’autre système nous a demandé de ralentir. | Rien. Attendez la prochaine exécution planifiée. | Tajo |
provider_unavailable | L’autre système était indisponible ou n’a pas répondu à temps. | Rien. Attendez la prochaine exécution planifiée. Si elle échoue de la même façon pendant une journée, envoyez-nous l’identifiant d’exécution. | Tajo |
connection_missing | Un outil utilisé par la synchronisation n’est pas connecté dans cet espace de travail ; l’exécution le nomme. | Connectez-le, puis relancez la synchronisation. | Vous |
connection_unauthorized | L’autre système a refusé notre accès. | Reconnectez la connexion pour obtenir une nouvelle autorisation, puis relancez la synchronisation. | Vous |
destination_rejected | La destination a rejeté tous les enregistrements de cette exécution. | Vérifiez le mapping des champs par rapport aux champs obligatoires et aux formats de la destination, puis relancez la synchronisation. | Vous |
node_failed | Une étape de la synchronisation a échoué pendant la lecture, la transformation ou l’écriture des enregistrements. | Ouvrez l’exécution pour voir quelle étape a échoué et pourquoi, corrigez-la, puis relancez la synchronisation. | Vous |
attestation_rule_not_active | Cette synchronisation est en pause. | Réactivez la synchronisation pour l’exécuter. | Vous |
attestation_publication_not_attested | Cette version de la synchronisation n’a pas été publiée. | Publiez la synchronisation. Les modifications d’une synchronisation ne s’exécutent qu’une fois publiées. | Vous |
unclassified_exception | La synchronisation a échoué pour une raison que nous n’avons pas encore classée. | Relancez la synchronisation. Si elle échoue de la même façon, envoyez-nous l’identifiant d’exécution. | Tajo |
Ce qui peut mal tourner
- Retry répond “This sync rule is already running.” (cette règle de synchronisation est déjà en cours d’exécution). Une relance ou une exécution de test que vous lancez est refusée tant qu’une exécution de la synchronisation apparaît comme Queued ou Running, y compris une exécution dont le worker s’est arrêté. Pour une synchronisation que Tajo exécute selon un planning, cette exécution est fermée et remplacée dès qu’elle a démarré il y a plus d’une heure. Pour toute autre synchronisation, envoyez-nous l’identifiant d’exécution.
- Une synchronisation a échoué pendant plus de sept jours. Au bout de sept jours, le registre oublie une écriture terminée. Un lot rejoué après ce délai peut écrire de nouveau des enregistrements : vérifiez la destination à la recherche de contacts en double.
- Une synchronisation reste muette alors qu’une autre fonctionne. La vérification horaire surveille l’espace de travail, pas chaque synchronisation. Une synchronisation en bonne santé masque une synchronisation muette dans le même espace de travail : lisez donc le Run history de chaque synchronisation.
- Vous voulez d’autres limites. La pause après cinq échecs et la vérification sur 24 heures sont réglées pour l’ensemble du déploiement Tajo, pas par synchronisation.