Dinoer

The operation takes a while, and you see nothing until it ends

A clone, an import, a bulk update. Dinoer reports once, at the end — so a failure at thirty seconds costs you the full wait. Why a timeout is not a failure, and the one dial that actually helps.

The symptom. You trigger something slow — a site clone, an import, a bulk update — and wait. Dinoer answers once, at the end. Meanwhile the interface may be showing a spinner, a progress bar, live logs: none of it reaches you until the run finishes.

If the operation fails after thirty seconds, you find out three minutes later. And every iteration of your scenario costs the full duration again.

Why it works this way

One invocation, one final answer — a terminal observation, not a stream. That is what makes a run reproducible and its output a single readable JSON, and it is exactly the cost of this situation: there is no intermediate view, because Dinoer produces no image at all, in any mode, to sample one from.

Wait for a signal, not for a duration

Do not use pause to wait for an operation to finish.

A fixed pause cannot adapt. Set it to ten seconds and an operation that takes fifteen gives you an answer read while the job is still running; one that takes two wastes eight seconds on every iteration. Both failure modes are silent.

[
  {"type": "cliquer", "selecteur": "#start-clone"},
  {"type": "attendre_absence", "selecteur": ".spinner"},
  {"type": "attendre_selecteur_present", "selecteur": ".result-container"},
  {"type": "extraire_texte"}
]

Wait for the spinner to leave, then for the result to arrive. The scenario now takes exactly as long as the operation does — no more, no less. Keep pause for what it is good at: a deliberate delay, not a bet on a duration.

Raise --timeout for the whole operation

/opt/dinoer/venv/bin/python3 /opt/dinoer/rpa.py \
  --scenario clone.json --timeout 300000 --guide-version 1.6

--timeout (default 10,000 ms) applies per Playwright operation — a long mutating action usually needs it raised well beyond the default. There is no separate capture timeout to reason about, because there is no capture step in this tool.

A timeout is not a failure — check before retrying

A submission that hits the timeout may have succeeded. The server does not stop working because the client stopped waiting.

Observed for real: a clone triggered by a classic POST, no AJAX, so the HTTP request stayed open until the server finished. The click ended in TimeoutError after twenty seconds. The clone had already been launched and completed — confirmed the hard way, by re-running the operation “cleanly” with a generous timeout and getting a second identical clone.

So before retrying a long mutating operation: go and look at the target. A TimeoutError on a click means Playwright stopped waiting, nothing more.

In short

  • Dinoer reports once, at the end — no intermediate view exists to ask for.
  • Wait for a DOM signal, never for a fixed duration.
  • --timeout covers each Playwright operation; raise it for the whole scenario when the operation itself is slow.
  • Never retry a slow mutating action without checking the target first — you may be doing it twice.