Ma soumission dans le navigateur a-t-elle abouti avant l’arrêt ?

Pourquoi un lot en échec peut-il quand même créer un enregistrement ?

La ligne INV-1042 remplit un formulaire de facture et clique sur Envoyer. Le serveur accepte la facture, puis la connexion se ferme avant que le navigateur affiche le reçu. Le processus local voit une interruption, mais la facture peut déjà exister dans le système métier. Répéter le clic risque de créer un doublon.

Il faut donc vérifier si l’effet attendu existe, et pas seulement si l’automatisation s’est terminée correctement. La même incertitude concerne une écriture HTTP ou un outil MCP qui expire : l’action distante peut se terminer après que le client a cessé d’attendre.

Que vérifier avant de réessayer ?

1. Lisez le rapport du lot et relevez la ligne en revue, sa clé métier et le compte de destination.
2. Recherchez cette clé dans la destination. Comparez les champs qui définissent l’opération : pour une facture, sa référence, son client, son montant et sa période.
3. Si l’effet existe, notez son reçu ou son identifiant, puis résolvez la ligne en done.
4. Si vous avez établi que l’effet n’a pas eu lieu, résolvez-la en failed. Une reprise ultérieure pourra la soumettre.
5. Si les preuves ne suffisent pas, laissez la ligne en revue. Une recherche vide pendant un traitement différé ne prouve pas toujours l’absence de l’enregistrement.

La résolution manuelle exige une note de preuve et la confirmation explicite qu’une personne a vérifié la destination. Elle est enregistrée comme une décision manuelle non vérifiée. Un agent doit demander à l’utilisateur de confirmer cette vérification avant de définir confirmChecked. Voir le guide de reprise pour les commandes exactes.

Comment Ritoko reprend-il les autres lignes ?

Reprenez le lot existant : utilisez run_resume pour une exécution directe ou host_next pour une exécution pilotée par l’hôte. Les lignes confirmées le restent. Les échecs antérieurs à la soumission peuvent être réessayés ; les écritures incertaines restent bloquées. Le lot réutilise le workflow et l’instantané d’entrée enregistrés : modifier le tableur ne réécrit pas le lot interrompu.

Un lot ultérieur utilisant le même workflow, périmètre et clé respecte aussi la mise en revue. Si un autre lot est bloqué par l’élément incertain d’origine, résolvez d’abord le lot initial. Ne contournez pas l’incertitude en changeant le nom du workflow, le périmètre ou le journal.

Comment faciliter la résolution d’une prochaine interruption ?

Marquez l’unique opération irréversible avec commit: true, puis vérifiez un résultat propre à la ligne avec expect. Un bandeau « Succès » générique constitue une preuve faible ; une référence correspondante ou un reçu est plus utile. Considérez aussi un champ à sauvegarde automatique ou un téléversement qui crée un enregistrement comme une écriture.

Ritoko suit les actions de cette installation. Il ne voit pas les soumissions indépendantes, ne rend pas un site distant idempotent et ne déduit pas le résultat en l’absence de preuve. Séparez les tâches comportant plusieurs effets irréversibles en procédures dont chaque résultat peut être vérifié.