Jetpack: can't enable Manage module

[jeherve]

Steps to reproduce

1. Starting on an existing Jetpack site where the Manage module is disabled.

1. Click to enable the Manage module in the Plugins card.
2. See that some plugins are out of date in that same card.
3. Click on the link to enable auto-updates. It redirects you to wordpress.com/plugins/yoursite.com
4. There, you receive a message that Manage isn't active. But it is.

1. Clicking on the button to enable Manage redirects me to mysite.com/wp-admin/admin.php?page=jetpack&configure=manage&section=plugins#/

1. Clicking on that button reloads the page, but Manage status appears to stay the same. I see a call to /wp-admin/admin.php?page=jetpack&action=activate&module=manage&_wpnonce=nonce that returns a 302. Here are the response headers:

Cache-Control:no-cache, must-revalidate, max-age=0
Connection:keep-alive
Content-Type:text/html; charset=UTF-8
Date:Mon, 03 Oct 2016 10:39:51 GMT
Expires:Wed, 11 Jan 1984 05:00:00 GMT
Location:http://mysite.com/wp-admin/admin.php?page=jetpack&configure=manage&section=plugins
P-LB:lb1.q2.sat
P-WS:web3.q2.sat
Server:nginx
Set-Cookie:jetpackState[module]=manage; path=/wp-admin; domain=mysite.com
Set-Cookie:jetpackState[error]=module_activation_failed; path=/wp-admin; 
domain=mysite.com
Set-Cookie:jetpackState[error]=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/wp-admin; domain=mysite.com
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN

[oskosk]

I couldn't reproduce right away. Manage seemed to be already enabled for me after clicking the link and when reaching Calypso's plugins page. I'm going to try to reproduce again, by cleaning local storage (IndexedDB) and doing it all over.

Also, while trying to reproduce this, I found a bug in Jetpack's Admin Page, (fix proposed in Automattic/jetpack#5245) . This bug was avoiding a redirection after clicking the enable Manage link. I don't think this bug is directly involved in the error you've encountered, but the steps mentioned here for reproducing it, would have been different if this bug hadn't been there.

Note: Mentioned bug was present on Jetpack latest master and not in Jetpack 4.3.1

[oskosk]

@jeherve you experienced this with Jetpack 4.3.1 , not with Jetpack master right?

[oskosk]

I've just reproduced with 4.3.1 BUT while I was staring at the plugins page, it updated itself to show that Manage was indeed enabled. Like if it had synced it a few seconds after I enabled OR Jetpack somehow is caching Manage's state.

[oskosk]

Even after force-refreshing Calypso's plugin page, the old state remained until some update was received about Manage state.

[jeherve]

Like if it had synced it a few seconds after I enabled OR Jetpack somehow is caching Manage's state.

Right, that seems to be the issue for me too. But that's pretty annoying, and should not happen since I clicked that button to start using Calypso!

[lancewillett]

@oskosk Do you have a pull request or fix ready for review? What are the next steps to solve this?

[oskosk]

@lancewillett still digging this. The thing is that Manage is in fact enabled, but there's a certain time between Manage activation on the Jetpack side and .com being updated about its new state. This is what's being experienced here as reported by this issue.

[jeherve]

Also reported in P4evON-1e2-p2.

[beaulebens]

I believe this is simply a combination of:

• time it takes to sync the information about a module being enabled back to WP.com,
• combined with the periodic polling that currently happens on WP.com to load the most recent information about a site.

So you enable the module in Jetpack, then it has to sync that data over to WP.com (takes "some time"), then once the data is synced, and you're looking at Calypso, it only periodically polls for fresh information, so it takes "some time" before it gets the new data.

Until we have real-time data updates (push from WP.com to clients) I think we need some query parameter or something that we can pass around, which tells Calypso to force-refresh the data for this site.

[lancewillett]

+1 on the suggested solution from Beau to use a query parameter to force-reload data rather than waiting on the normal sync schedule.

[jeherve]

Looks like a related issue in p2JiWH-1Aj-p2.

[lancewillett]

Is anyone working on this one? What's the next step to wrap it up?

[tyxla]

@lancewillett I was able to reproduce it today, and if I'm correct about my assumption, the fix is pretty straightforward - see #12715.

[tyxla]

A fix for this was applied in p7rcWF-l0-p2 (thanks @lezama). Since then I've tried to reproduce it multiple times, with no luck.