Flaky E2E: Go to the new post page

[worldomonation]

Spec file

specs/blocks/blocks__jetpack-earn.ts

TeamCity ID

10915856

Logs

Error: Timed out waiting for the Editor
at EditorComponent.parent (/home/teamcity-1/buildAgent/work/c4a9d5b38c1dacde/packages/calypso-e2e/src/lib/components/editor-component.ts:39:10)
    at EditorWelcomeTourComponent.forceToggleWelcomeTour (/home/teamcity-1/buildAgent/work/c4a9d5b38c1dacde/packages/calypso-e2e/src/lib/components/editor-welcome-tour-component.ts:28:24)
    at EditorWelcomeTourComponent.forceDismissWelcomeTour (/home/teamcity-1/buildAgent/work/c4a9d5b38c1dacde/packages/calypso-e2e/src/lib/components/editor-welcome-tour-component.ts:72:3)
    at EditorPage.waitUntilLoaded (/home/teamcity-1/buildAgent/work/c4a9d5b38c1dacde/packages/calypso-e2e/src/lib/pages/editor-page.ts:131:3)
    at EditorPage.visit (/home/teamcity-1/buildAgent/work/c4a9d5b38c1dacde/packages/calypso-e2e/src/lib/pages/editor-page.ts:113:3)
    at Object.<anonymous> (/home/teamcity-1/buildAgent/work/c4a9d5b38c1dacde/test/e2e/specs/blocks/shared/block-smoke-testing.ts:48:4)

#80730

[worldomonation]

This has really spiked in the last couple of weeks.

[worldomonation]

and is happening across various specs that involve the editor.

[worldomonation]

holy cow.

[worldomonation]

Something I've noticed: they are mostly, if not all, coming from the Jetpack Private site user.

[worldomonation]

My guess, mostly a hunch from the years of experience writing tests against Calypso, is that we aren't waiting long enough for the cookie to settle after the user login step.

It's hard to explain, but what I've observed happen in the past is that if we don't wait long enough for the redirect to /home to happen, the login is treated as if it failed.

On Simple sites the processing is done quite fast and so this is usually not a problem, plus the POMs we have developed over the years effectively waits for the cookie to settle. However, AT sites process much more slowly.

My guess is that when the login process is occurring, the current implementation of the POMs is essentially firing "done" sooner than it should. This leaves the slow AT users in a partially-logged in state.

Furthermore, the "done" signal lets Jest move on to the next step in the test, which in the case of Editor/Block related tests, is to directly navigate to the Post Editor URL.

Because the login process didn't exactly complete though, the navigation fails because the editor only loads if the user is fully authenticated.

Anyway, this is just my guess - we will probably have to iterate on any fix for this to see if it sticks.

[dpasque]

This has been really tricky to debug. Ultimately, it's an issue with Jetpack SSO on these atomic sites. However, now that we've scaled back our parallelization, we are hitting this a lot less. So I think we can bump down to normal, and put on the backlog.

[dpasque]

For future us: the issue was caused by the jetpack SSO redirect loop not working, and getting stuck essentially in a redirect loop.

Here's how it goes:

• We try to navigate to the editor on the atomic host at post-new.php
• We only have a cookie for wordpress.com, so we are unauthed on the atomic host. It redirects us to the atomic host at wp-login.
• We get redirected to wordpress.com/wp-login.php?action=jetpack-sso to do the SSO login using the cookie we have from the initial login.
• We get redirected back to the atomic host wp-login to finish the SSO, with action=jetpack-sso&result=success

All of ☝ is so far correct!

What then fails is that it then redirects us back to the editor on the atomic host at post-new.php, but for whatever reason, it's not buying our auth, and starts the whole loop again (returns a 302, starts the login loop).

So... Why is our Jetpack SSO auth not sticking when we land back in the editor?