probeTimeoutMs of 1500 is too short on our staging box — every candidate scores 0
Asked 5,030 views2 answers
17votes
Locally everything heals. On staging the same locators fail with HEAL_FAILED and every candidate in the hint reads 0.00, including ones I know match, because I can open the page and see them.
Staging is a shared box and slow, so my guess is that the probes are timing out. What I cannot tell from the event is the difference between "probe timed out" and "matched nothing" — both come out as zero.
Your guess is right and the ambiguity is real. A probe that times out is caught and recorded as count: 0, visible: false, enabled: false, score: 0, which in the hint is indistinguishable from a candidate that genuinely matched nothing.
The ms field on each candidate is the tell — anything sitting right at your probeTimeoutMs timed out rather than answered.
Also worth knowing: probeTimeoutMs caps the whole probe, not each call inside it. The count, the visibility check and the enabled check all race the same deadline, so three round trips inside 1500 ms on a slow environment is tight.
Raise it for that environment only, since the env layer may override heal:
yaml
heal:
probeTimeoutMs: 4000
in envs/staging.yaml. Budget for it, though — the worst case per failing locator is primaryTimeoutMs plus probeTimeoutMs, so you have just moved four and a half seconds to seven.
Agreed on the fix. Before you settle there, look at primaryTimeoutMs too. If staging needs four seconds to render, the primary is timing out on elements that are merely late rather than gone, and you are paying the full heal cost on locators that were never broken. Those show up in sdods heal report --last as heals whose winning selector is effectively the primary.
Raising primaryTimeoutMs on that environment is cheaper than healing your way through it.