The page never finishes loading, whatever timeout you set
Ten seconds fails. Forty-five seconds fails the same way. The target is not slow: it never finishes, and no timeout will change that.
The symptom. TimeoutError on the first navigation. You raise
--timeout from 10 s to 45 s, and it fails again, in exactly the same way.
That identical failure is the diagnosis: the problem is not the duration.
What Dinoer is waiting for
By default, the first navigation completes on networkidle: 500 ms without
network traffic. It is a good default, because it means the page has really
settled: scripts have run, content has arrived.
Some targets never go quiet. A dashboard that refreshes its counters, a live statistics panel, the administration page of a router that polls its own status: they keep using the network by design. There is no quiet moment to wait for, so Dinoer waits until the timeout, every time, whatever its length.
Change the condition, not the duration
/opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
--url http://target.local/ --wait-until load --a11y \
--guide-version 1.6
--wait-until load completes when the page’s own load event fires, without
requiring network silence. The same option exists on rpa.py. It applies to
the first navigation only, not to naviguer actions, and the escalations
started by campagne.py keep the default.
A scenario can carry it as a root property, so that whoever reuses it does not need to know the quirk of the target:
{"url": "http://target.local/", "wait_until": "load", "actions": [...]}
The command line wins over the scenario This option carries a value, and two values cannot be combined. If both are set, the command-line option decides.
Which value to use
| Value | Completes on | Use it when |
|---|---|---|
networkidle | 500 ms without network traffic | the default: keep it unless it fails |
load | the page’s load event | the target polls continuously |
domcontentloaded | HTML parsed, other resources still loading | you need the earliest possible view |
Do not switch to load in advance. The default gives you a page that has
finished arriving; changing it means accepting that some content may still be
loading when the answer is produced. Change it when the default fails.
How to tell it from a slow page
A slow page succeeds if you wait long enough: raising the timeout changes the outcome. A page that never goes quiet fails the same way at any duration.
The test is cheap: run it once with the default timeout and once with a much larger one. Same failure, same speed? Change the condition. Different behaviour? You have an ordinary slow target, and the timeout is the right setting.
In short
- The same failure at 10 s and at 45 s means the wrong condition, not the wrong duration.
--wait-until loadfor targets that poll continuously.- Put it in the scenario so that it travels with the target.
- Keep
networkidleeverywhere else.