Describe the bug
Related to https://github.com/woocommerce/woocommerce-ios/issues/678
Basically if we log in and the sites are not accessible for some reason - it isn't possible to log out and log in as a different user which makes the troubleshooting workflow difficult (the only way is to re-install the app).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I'd hope to be able to log in as a different user if I'm unable to access a site as this particular user. Not sure if that's the best flow for regular users but this would definitely make troubleshooting easier as we wouldn't have to re-install the app to access a different account.
Isolating the problem (mark completed items with an [x]):
Mobile Environment
Please include:
WordPress Environment
Copy and paste the system status report from **WooCommerce > System Status** in WordPress admin.
Thanks for logging this @grigorijurasov 😄
Just providing a little visual context here → the WPAuthenticator epilogue screen (aka store picker) is presented as a full-screen modal without a back button:

it isn't possible to log out and log in as a different user which makes the troubleshooting workflow difficult (the only way is to re-install the app).
@grigorijurasov until we fix this, just a heads up that if you kill the app while on the store picker screen, the next time you run the app you will be back at the beginning of the login flow. DM me if you have any questions :-)
Re: https://github.com/woocommerce/woocommerce-android/issues/954#issuecomment-481331493:

We could enable the "Try another account" button on the WCiOS store picker too.
/cc @kyleaparker 😄
As I mentioned in https://github.com/woocommerce/woocommerce-android/issues/954, this will be solved with the Sign In project:

In the meantime, we can add secondary buttons for "Try another account" on both the screen that has stores and the screen without. Let's follow the same design as the WP iOS app:

More context https://github.com/woocommerce/woocommerce-ios/pull/1030#pullrequestreview-249460525
@jaclync this one might interest you. It's up for grabs if you feel like working in navigation.
hmm I had trouble reproducing this issue, what I've tried:
@grigorijurasov could you give me more details on how I can reproduce this issue? Like in which step I go offline or how to make a site inaccessible?
@jaclync Steps to Reproduce:
More context and background here: https://github.com/woocommerce/woocommerce-ios/pull/1030#pullrequestreview-249460525
Thanks for the steps to repro, I misunderstood the "connection issues".
I just logged into a WP.com without any WC store on my device, and when I tapped "Try another account", it led me back to the log in screen. It seems like a reasonable flow?
There are certain steps during the login flow that you can take, where the view controllers lose their nav controller. I can't remember exactly how to reproduce it, but I know it hasn't been fixed.
Maybe try a WooCommerce account with an invalid store and no valid stores?
Maybe try a WooCommerce account with an invalid store and no valid stores?
What does an "invalid store" mean in this case, and how can I create one?
That was poor phrasing :) A store that is using WooCommerce version 3.4 or older. I'll DM you.
In the case of 1924167-zen, the user has an alternate XML-RPC route listed in the Jetpack Debugger tool. This can cause our API request to receive a response with a no_response_body error message.
Reproduced the error with the provided information. Per p99K0U-1By-p2, the problem was from the user's configurations. The app UI doesn't need changed. After the fix is released on Jetpack, this issue will be closed.
If any further cases are found, have a mobile dev check the API request and determine if its a 500 server error. This "login limbo state" + 500 error that users are getting into continues to hint at unusual server configurations.
Apologies @jaclync for marking this as a "good first issue". Login problems continue to be rabbit holes, not good first issues.
Jetpack fix deployed
sorry I haven't got to create a self-hosted store yet, thanks for fixing! is the fix on the Jetpack backend? any PR we could link here for more details about the fix?
Yep, the fix was made on the Jetpack side. Their code isn't public as far as I know. Ref. p99K0U-1By-p2.
Re-opening. I solved the problem for the use case that was listed, but I didn't end up adding the "Try another account" button. I see what Gregorij is getting at. The flow can still be broken for some users (in situations that we haven't identified yet). So the "Try another account" button should be present regardless of whether or not the stores can connect successfully.