Wp-calypso: Jetpack Version is Stale

[gwwar]

The Jetpack version in Calypso state may be stale, causing issues when we change Jetpack versions during upgrade or testing. The Jetpack version is used to determine things like if we should enable certain features or redirect to specific areas.

To reproduce this issue:

• Connect a Jetpack Site
• Install the Jetpack Beta Plugin
• Choose Bleeding Edge
• Visit https://wpcalypso.wordpress.com/block-editor/yoursite/post/X
• Verify that we can edit in the block-editor
• Update settings in the Jetpack beta plugin to latest released version (not bleeding edge)
• Visit https://wpcalypso.wordpress.com/block-editor/yoursite/post/X?debug

The incorrect version is read:

state.sites.items[ state.ui.selectedSiteId ].options.jetpack_version returns 7.3-alpha instead of 7.2.1

I would recommend adding a query component to update this value more consistently. Maybe in layout since this is used in many views.

[mmtr]

A quick update before further investigating this. Seems that problem is with the /me/sites endpoint returning a cached value.

We already have a query component that updates the options of all sites (including the jetpack version) on the layout (#).

That query component makes an API request to /me/sites but the response contains a cached jetpack_version value for my test JP site (7.3-alpha instead of 7.2.1). I get the same response when testing manually on https://developer.wordpress.com/docs/api/console/. However I noticed that the /sites/:site endpoint returns accurate data.

[mmtr]

I'm facing a wall and I don't know how to get any progress on this, so I'm going to leave it here and hopefully someone else can identify what I'm missing.

For some reason, the WP.com-side of the Jetpack site has a wrong value for the blog option that stores the identify the JP version which is the value we return on calls to /me/sites (see public.api/rest/sal/class.json-api-site-jetpack-shadow.php#L258 and wp-content/mu-plugins/misc.php#759).

That value comes from a constant that Jetpack syncs back to WP.com (#).

Maybe the Jetpack Beta plugin is not updating that constant when switching between stable, RC and bleeding edge? Or maybe Jurassic Ninja sites have some kind of limitation that prevents from syncing the constants?

[obenland]

@Automattic/jetpack-crew Do you have any advice on that? ^

[kwight]

Maybe the Jetpack Beta plugin is not updating that constant when switching between stable, RC and bleeding edge? Or maybe Jurassic Ninja sites have some kind of limitation that prevents from syncing the constants?

I still have this issue on my local JP (not JN), and after disabling the beta plugin and downgrading Jetpack (by checking out the 7.2 SHA).

[kwight]

Noting also that I don't think we should consider this a blocker; any users with 7.2 and lower are properly handled (they are sent to wp-admin via Calypsoify). It only affects those that have the jetpack_version successfully synced at >=7.3, then downgrade.

[gwwar]

What's the time to cache invalidation for that response @mmtr ? If folks have a stale value, on upgrade they also won't get new features until that happens or until they happen to clear browser cache. Agree that this isn't a blocker, but would be nice to clean up a bit.

[kwight]

I've verified this was fixed by @enejb in D27700-code. 🎉