L'opération prend un certain temps, et vous ne voyez rien tant qu'elle n'est pas terminée
Un clone, une importation, une mise à jour massive. Dinoer signale une fois, à la fin ; donc, un échec après trente secondes vous fait perdre tout le temps d'attente. Pourquoi un délai d'attente n'est pas considéré comme un échec, et quel paramètre est réellement utile.
Le symptôme. Vous lancez une opération longue — une copie de site, un import, une mise à jour massive — et vous attendez. Dinoer ne répond qu’une seule fois, à la fin. Pendant ce temps, l’interface peut afficher un indicateur de chargement, une barre de progression, des logs en direct : rien de cela ne vous parvient tant que l’opération n’est pas terminée.
Si l’opération échoue après trente secondes, vous le découvrez trois minutes plus tard. Et chaque itération de votre scénario coûte à nouveau toute la durée complète.
Pourquoi cela fonctionne de cette manière
Une seule invocation, une seule réponse finale — une observation terminale, pas un flux. C’est ce qui rend une exécution reproductible et sa sortie un seul fichier JSON lisible, et c’est exactement le prix à payer pour cette situation : il n’y a pas de vue intermédiaire, car Dinoer ne produit aucune image du tout, dans aucun mode, pour en prévisualiser une.
Attendez un signal, pas une durée
Ne pas utiliser
<code>pause</code>pour attendre la fin d’une opération.
Une pause fixe ne peut pas s’adapter. Si vous la réglez sur dix secondes et qu’une opération prend quinze secondes, vous obtiendrez une réponse pendant que le travail est toujours en cours ; une opération qui prend deux secondes gaspillera huit secondes à chaque itération. Les deux modes de défaillance sont silencieux.
[
{"type": "cliquer", "selecteur": "#start-clone"},
{"type": "attendre_absence", "selecteur": ".spinner"},
{"type": "attendre_selecteur_present", "selecteur": ".result-container"},
{"type": "extraire_texte"}
]
Attendez que le curseur disparaisse, puis que le résultat s’affiche. Le scénario
dure désormais exactement aussi longtemps que l’opération elle-même : ni plus, ni moins. Utilisez
pause pour ce qu’il est conçu pour : un délai délibéré, et non une estimation de durée.
Augmenter --timeout pour l’ensemble de l’opération
/opt/dinoer/venv/bin/python3 /opt/dinoer/rpa.py \
--scenario clone.json --timeout 300000 --guide-version 1.6
--timeout (par défaut 10 000 ms) s’applique à chaque opération Playwright ; une action de mutation longue nécessite généralement d’augmenter cette valeur bien au-delà du paramètre par défaut. Il n’y a pas de délai d’attente de capture distinct à prendre en compte, car cet outil ne comporte aucune étape de capture.
Un délai d’attente n’est pas une erreur ; vérifiez avant de réessayer
Une requête qui dépasse le délai imparti peut avoir réussi. Le serveur ne cesse pas de fonctionner simplement parce que le client a cessé d’attendre.
Observé dans une situation réelle : un clonage déclenché par une requête POST classique, sans AJAX, donc la requête HTTP est restée ouverte jusqu’à ce que le serveur ait terminé. Le clic s’est terminé après vingt secondes à TimeoutError. Le clone avait déjà été lancé et complété — confirmé de manière concrète en relançant l’opération “proprement” avec un délai d’attente généreux, et en obtenant un second clone identique.
Avant de réessayer une opération longue qui modifie l’état : allez vérifier l’élément cible. Un
TimeoutError lors d’un clic signifie que Playwright a arrêté d’attendre, rien de plus.
En bref
- Dinoer signale une fois, à la fin ; aucune vue intermédiaire n’existe pour demander des informations.
- Attendez un signal DOM, et non une durée fixe.
--timeoutcouvre chaque opération Playwright ; déclenchez-le pour l’ensemble du scénario lorsque l’opération elle-même est lente.- Ne retentez jamais une action de mutation lente sans vérifier d’abord la cible ; vous pourriez la faire deux fois.