We are behind an identity provider, so:
auth:
strategy: ssoEvery @ui scenario now fails, but not with an auth error — with a pile of locator timeouts, because the page is /login and none of the things the steps look for are on it.
sdods doctor is clean. Nothing in the run output mentions authentication at all. Where is the error?
Accepted answer
There is no error because the sso case is a stub. Its login function resolves to nothing: no storage state written, and nothing thrown. You get a clean unauthenticated browser context and the failure surfaces thirty seconds later as whatever locator was unlucky enough to be first.
Open issue — the minimum fix is for it to raise an auth failure instead of returning quietly, and that has not landed.
The path that does work is the interactive capture, which is what the auth guide describes for sso:
sdods auth capture -p <slug> -e staging --user standard --interactiveThat opens a codegen window, you complete the SSO round trip by hand, and it writes the storage state that the fixture then applies to every scenario for that role. The config value does not do this for you; you do it once per role and the runs reuse it.
So: keep strategy: sso for documentation if you like, but understand that the captured state is the thing actually logging you in.
One consequence of the above that bites on a schedule rather than immediately.
The fixture re-captures form and token state by itself once it is older than auth.maxAgeMinutes. It cannot re-capture sso state, because the capture is interactive by definition. So a nightly will run fine for as long as your provider's session lives and then start failing in exactly the way Fiona describes, with no message.
Give yourself a signal: a @smoke scenario per role that asserts on something only a signed-in user sees, and put it first. Then a stale capture fails one obvious scenario instead of two hundred obscure ones.
Have a different question? Ask it.