net::ERR_ABORTED on an authenticated route is our single biggest source of failures
Asked 8,730 views3 answers
47votes
Top error signature in a clean single-worker run, by a wide margin:
text
page.goto: net::ERR_ABORTED at https://staging-app.example.com/workspace/<uuid>/home
55 of the 192 failures I captured, plus a big pile of click timeouts that I am fairly sure are downstream of it. The step behind it is a page-object method that deep-links the workspace:
It is intermittent — the same scenario passes on a rerun maybe a third of the time. Failure screenshots are either a blank white page or the app frozen on "Loading session…". Our auth is client-side.
Is waitUntil: 'domcontentloaded' the wrong wait here?
Client-side auth attaches after the first authenticated route has loaded. Deep-linking an internal route lands before that bootstrap has finished, the client sees no user yet and issues a redirect to the login route, and the navigation you started is aborted by the one the client started. ERR_ABORTED is the precise symptom of that, and your two screenshots are the two halves of the race: blank if the abort came early, "Loading session…" if it came mid-bootstrap.
waitForURL cannot rescue it because it runs after goto resolves, and here goto is what rejects. And a retry around the navigation would only hide it.
There is an open issue. Nothing has been fixed, but the fix on your side is a page-object change and it is worth making now:
make the first authenticated navigation the only goto — enter at the app root once, let
the session attach
reach the deep target the way a person does, through the switcher or the sidebar
if you must keep a deep link somewhere, wait on a test id that only exists once the shell has
That needs a stable test id on the switcher options. If your app does not have one yet, that request is the highest-value thing you can put in front of your developers this week.
The ones inside step files are the easy ones to miss, and they are on the paths that hurt — deep links into a builder or a settings surface. The single legitimate goto is the first entry after login; everything else should be navigation.
Also worth a review rule, because a comment does not hold. We had this documented in the page object itself, nine lines above the call that broke it.
We added a workspace-shell test id and waited on that instead of domcontentloaded, which cut it a long way down but not to zero — the very first entry of the run still has to happen somewhere, and that one is still a goto. Doing it once per worker in a fixture rather than once per scenario is what got the last of it.
Also: do not re-baseline anything until this is fixed. Several hundred of our scenarios go through that step, so the reported state of most UI modules was a report on this bug.