L’opération dure plusieurs minutes, et vous ne voyez rien avant la fin

Le symptôme. Vous lancez quelque chose de lent — le clonage d’un site, un import, une mise à jour en masse — et vous attendez. Diwall capture une fois, à la fin. Pendant ce temps, l’interface affiche peut-être un indicateur de chargement, une barre de progression, des journaux en direct : vous n’en voyez rien.

Si l’opération échoue au bout de trente secondes, vous l’apprenez trois minutes plus tard. Et chaque itération de votre scénario coûte à nouveau toute la durée.

Pourquoi il fonctionne ainsi

Diwall, c’est un appel et une capture finale. Une observation au terme, pas un flux — c’est ce qui rend une exécution reproductible et sa sortie lisible en un seul JSON. Le prix de ce choix, c’est exactement cette situation.

Capturer en chemin

interval_capture prend une capture toutes les N secondes pendant une attente. C’est un paramètre par action, disponible sur attendre, pause et attendre_navigation :

{"type": "attendre", "selecteur": ".clone-done", "interval_capture": 10}

Les captures intermédiaires arrivent dans stream_captures[] de la sortie JSON. Vous attendez toujours la fin, mais vous avez ensuite une suite d’images au lieu d’une seule — de quoi voir où cela a cassé, et pas seulement que cela a cassé.

--interval-capture N en ligne de commande fixe une valeur par défaut pour toutes les actions qui l’acceptent ; la valeur donnée dans l’action l’emporte.

Attendre un signal, pas une durée

N’utilisez pas pause pour attendre la fin d’une opération.

Une pause fixe ne s’adapte pas. Réglez-la à dix secondes : une opération qui en prend quinze vous donne la capture périmée d’un travail encore en cours ; une qui en prend deux gaspille huit secondes à chaque itération. Les deux défaillances sont silencieuses.

[
  {"type": "cliquer_som", "id": 7},
  {"type": "attendre_absence", "selecteur": ".spinner"},
  {"type": "attendre_selecteur_present", "selecteur": ".result-container"},
  {"type": "capturer", "nom": "result"}
]

Attendez que l’indicateur disparaisse, puis que le résultat arrive. Le scénario dure alors exactement le temps de l’opération — ni plus, ni moins. Gardez pause pour ce à quoi elle sert : un délai voulu, pas un pari sur une durée.

Deux délais, et ce n’est pas le même

Une opération longue demande en général de relever le premier. Relever le second n’aide que si c’est la capture qui dépasse le délai — une page très haute, un rendu lourd.

diwall-rpa --scenario clone.json --timeout 300000 --guide-version 1.3

Un délai dépassé n’est pas un échec — vérifiez avant de réessayer

Un envoi qui dépasse le délai a peut-être réussi. Le serveur ne s’arrête pas de travailler parce que le client a cessé d’attendre.

Constaté pour de vrai : un clonage déclenché par un POST classique, sans AJAX, donc une requête HTTP restée ouverte jusqu’à ce que le serveur ait fini. Le clic s’est terminé en TimeoutError au bout de vingt secondes. Le clonage était déjà lancé, et il a abouti — ce qu’on a appris à ses dépens, en relançant l’opération « proprement » avec un délai généreux et en obtenant un second clone identique.

Donc, avant de réessayer une opération longue qui modifie quelque chose : allez regarder la cible. Un TimeoutError sur un clic veut dire que Playwright a cessé d’attendre, rien de plus.

En bref

• interval_capture vous donne une suite d’images au lieu d’une seule.
• Attendez un signal du DOM, jamais une durée fixe.
• --timeout vaut pour chaque opération ; --screenshot-timeout, pour la capture seulement.
• Ne réessayez jamais une action lente qui modifie quelque chose sans regarder d’abord la cible — vous risquez de la faire deux fois.