The operation takes minutes, and you see nothing until it ends

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

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

Diwall works as one invocation, one final capture. It is a terminal observation, not a stream — which is what makes a run reproducible and its output a single readable JSON. The cost of that choice is exactly this situation.

Capture along the way

interval_capture takes a screenshot every N seconds during a wait. It is a per-action parameter, available on attendre, pause and attendre_navigation:

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

The intermediate shots land in stream_captures[] in the JSON output. You still wait for the whole run, but afterwards you have a filmstrip instead of a single frame — enough to see where it broke rather than only that it broke.

--interval-capture N on the command line sets a default for every action that supports it; the per-action value overrides it.

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 a stale capture of a job still running; one that takes two wastes eight seconds on every iteration. Both failure modes are silent.

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

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.

Two timeouts, and they are not the same one

A long operation usually needs the first one raised. Raising the second one helps only when the capture is what times out — a very tall page, a heavy render.

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

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

• interval_capture gives you a filmstrip instead of one final frame.
• Wait for a DOM signal, never for a fixed duration.
• --timeout is per operation; --screenshot-timeout is for the capture only.
• Never retry a slow mutating action without checking the target first — you may be doing it twice.