Wp-calypso: Connection: Timeout Error During Plan Set Up Causes Process to Stall

[tmmbecker]

I was in a chat with a user with two sites hosted at GoDaddy and they were trying to add a Premium plan to both. They came to us because the set up for the first plan failed and they were lost.

The connection was clearly broken, but in the midst of reconnecting, I noticed that there were some persistent timeout errors that happened after the initial connection. Waiting a few minutes, the errors cleared and the connection was fine.

BUT, when I walked him through purchasing the plan on the other site, the same timeout error occurred - even though the site had a good connection when we started - and then the process just stalled.

No exit button and no error message, just six whirring wheels. It sat like that for quite awhile before we just gave up. Had he not been in chat with me, he would have had no idea what to do next.

I don't know how many others are seeing this same thing, but certainly, we should have some timeout or limit on the process that stops those wheels and presents the user with a helpful error message.

Site URL: psaag.org
Jetpack Debug URL / VP MC: https://jetpack.com/support/debug/?url=http%3A%2F%2Fpsaag.org%2F

Site URL: www.armedviolencereduction.org
Debug: https://jetpack.com/support/debug/?url=http%3A%2F%2Fwww.armedviolencereduction.org%2F

1755945-hc, followed up in 949575-zen

Related: #18257

[beaulebens]

Definitely sounds like we need to catch those timeouts, and handle that errors state better!

[MichaelArestad]

In trying to recreate this, I got a plan and, during set up, disconnected it. I got the following error:

I think this error should have a button to contact Happiness. "Get help" probably.

To address this issue (with infinite spinners), we need to do something similar to the screenshot above where we grey out the ones that aren't completed. We also need a GlobalNotice to encourage folks to contact Happiness. Perhaps:
"We are having trouble setting up your site. Get help"

CC @enejb

[enejb]

I got the same screen. See

I noticed that the message in the yellow box is telling me to set thing up manually.

@rickybanister Can you help with this? How can we improve this flow for the user?

[rickybanister]

We are looking to deprecate this screen in favor of the new checklist feature on the my plan page. As we do that we probably need to either automatically re-try the auto-configuration or provide a 'try again' link.

Do you know exactly what part timed out @enejb?

cc @joanrho to consider with the checklist work and also @johnHackworth

[tmmbecker]

I just got this message too when adding a plan for one of my test sites, which prompted me to bump the priority on a replacement doc for the one linked there to en.support.

Quill will get a new Jetpack support doc for that done by the end of next week.

[enejb]

@rickybanister There are all sorts of errors that are possible. In my case I took the site offline completely. The API failed by not being able to return any plugins from the site.
Do you think we should send some time fixing this now?
When is the new checkmark page suppose to go live?

I think for now we could make the message that says "we can't automatically configure your site." more prominent and we should make it look like something actionable an error and tell our users what to do next. (install it yourself or contact support, link to happychat) The white link doesn't stand out. Even remove the Error fetching plugins notice since it doesn't help. We can display it somewhere else.

Can you help with this? @rickybanister

[rickybanister]

Do you think we should send some time fixing this now?

Fixing what exactly? If you took your site offline there's nothing we can do for you except give the manual instructions. It seems you tried to set up your plan while no chat operators were available as well, so you weren't give the option to get live help.

If live chat is available it displays as a larger white button. The smaller manual instructions link is a sort of unfortunate backup, we hope people don't have to take that route.

[rickybanister]

I suppose in the spirit of the original issue we should offer a 'try again' button in case of timeouts. It may give users false hope, but still worth a try. Or perhaps we could try twice behind the scenes without the user knowing it.

cc @johnHackworth as we move the functionality of this screen to the checklist we may want to explore quiet retries like we do for the connection flow.

[danjjohnson]

@rickybanister we now have a doc for this on the JP support site:
https://jetpack.com/support/installing-vaultpress-akismet/

We should probably link to that instead of https://en.support.wordpress.com/setting-up-premium-services/ where applicable.

[rachelmcr]

I came across this issue while scrubbing high priority issues, and have a few questions:

• Is this issue still high priority? (And is it on hold, waiting on Jetpack checklists?)
• Is there a good way to fake/reproduce timeout errors like this? I would like to re-test this issue and the overall flow for sites that face server timeouts, but I haven't come up with a way to do it. Taking the site offline while testing returns a different error that doesn't result in a stalled connection flow.

[enejb]

cc @sirreal since he might have a good idea what the status of the fix is.

[sirreal]

Thanks for the ping!

This definitely fits into the checklist project as we'll be wholly replacing this "Thank you page"/installer/provisioner.

My most recent work has been related to the plan/plugin setup install and setup. #26690 is currently under heavy review and development.

The existing process on the thank you page is problematic. This is likely a manifestation of one of its issues.

If we think it's worth it, I can spend some time trying to diagnose and improve this problem. Given that we're not entirely sure exactly what the problem was in this case and how to reproduce it, my preference would be to leave the existing implementation alone and wait for the new implementation started in #26690 as part of the Jetpack Checklist project with the expectation that it be more reliable and maintainable.

One of the complexities working with plugins in Calypso right now is that it's not a Redux implementation like most of our data store. Issue #24180 is tracking that, but no one is actively working on it right now. It's part of @Automattic/team-calypso's backlog, but they're focused on more high priority work right now.

Is there a good way to fake/reproduce timeout errors like this?

@rachelmcr Given that we're not sure exactly what was broking in this case, it's hard to know what to break to reproduce this.

For example, I've testing by blocking public-api.wordpress.com/rest/*/sites/*/plugins in Chrome, which leads to this view:

It's possible that some unhandled error in JavaScript broke the application so that the spinners continued to be displayed. It's really hard to say.

[sirreal]

I've moved this to "Bigger Than HACK Week".

[sirreal]

@rachelmcr Turns out missing keys will create the forever spinning problem. Try the flow with this request blocking enabled:

public-api.wordpress.com/rest/*/jetpack-blogs/*/keys

This is just one example that leads to the forever spinners, it may or may not be the actual problem the user experienced in this case.

Two potential "quick fixes" for this case:

• Migrate key querying to data layers to get request retries "for free".
• Better handle missing plugin keys from within the Thank you page.

[simison]

Given that we're not entirely sure exactly what the problem was in this case and how to reproduce it, my preference would be to leave the existing implementation alone and wait for the new implementation started in #26690 as part of the Jetpack Checklist project with the expectation that it be more reliable and maintainable.

So the old flow is gone and the new checklist flow is in place. New flow still has some rough corners but I'd rather have them in fresh issues in case this is still relevant.

Thanks everyone!