Woocommerce-admin: Onboarding: Object caching prevents TOS from being accepted

[joshuatf]

Describe the bug
If some form of object caching is in place, the woocommerce_setup_jetpack_opted_in gets updated at the start of the profiler, but does not correctly update wc_connect_options afterwards.
Reading woocommerce_setup_jetpack_opted_in returns false until the cache is flushed.

This issue was first noted on a Pressable site, which uses memcached, but appears to persist across different forms of object caching.

This may or may not have something to do with how this option is updated via the REST options endpoint that somehow bypasses the update_option check made by a caching function.

To Reproduce
Steps to reproduce the behavior:

1. Install some form of object caching. W3 Total Cache is an easy one and using the standard "Disk" caching is sufficient to recreate the issue.
2. Delete wc_connect_options and woocommerce_setup_jetpack_opted_in from your wp_options table.
3. Make sure Jetpack is connected.
4. Flush your cache.
5. Visit the first step of the onboarding profiler.
6. Continue to the next step and complete the profiler, using a country applicable for tax automation (e.g., U.S.).
7. Visit the Tax task and refresh if necessary to note that the "Good news!" screen for automation is not shown until flushing the cache again.

Expected behavior
Expected the TOS option to be retrieved with the correct value and to allow usage of components that require its acceptance.

Screenshots

[joshuatf]

In W3 Total Cache, this appears to be the hook that checks for updates to options and should be flushing the cache - https://github.com/W3EDGE/w3-total-cache/blob/b80b957a5e8e139b1d104f4ef31f110732bb63cf/ObjectCache_Plugin.php#L83

[joshuatf]

After testing this a bit more, it looks like the problem here is that requests to non-admin URLs don't invalidate the object cache.

https://github.com/W3EDGE/w3-total-cache/blob/b80b957a5e8e139b1d104f4ef31f110732bb63cf/ObjectCache_Plugin.php#L342

Prior to making any other updates that would invalidate cache, we can manually check that woocommerce_setup_jetpack_opted_in is set to 1 in the database, but retrieving this value via WP returns false so wc_connect_options is never properly set.

This may be a similar issue to the one we experience with Pressable, but planning on looking into that further. I imagine this may be an issue with a number of caching plugins. While, I feel that POST requests to REST APIs should be a potential trigger to flush the cache, it may be worth looking into adding a filter (if one exists for a given plugin) to invalidate cache upon hitting certain routes.

[joshuatf]

Tested this with a couple other caching plugins that make use of Memcached and Redis and did not encounter this issue. Those had cache mechanisms that ran on every request, regardless of whether or not it was an admin request, and updated the cache accordingly.

Had a Zoom chat with @timmyc about this and after some discussion it feels like trying to create workarounds for various plugins inside wc-admin will be hacky and result in more trouble than it's worth.

It may be worth considering opening PRs with the plugins causing this to offer a better fix.

[joshuatf]

Here are the most popular plugins with object caching.

Working

• Simple Cache
• Wp-memcached
• LiteSpeed Cache (Redis & Memcached)

Not working

• W3 Total Cache - This appears to be due to object cache invalidation not being triggered via any REST requests. We may want to consider opening an issue on this repo as this affects most functionality across wc-admin where updates are made via the REST API. Here are the guidelines for contributing.
• Pressable - Uses the wp-memached object cache found here. That object cache independently works as expected, but there are apparently some other caching updates that occur outside of that script which may be causing the issue. More updates to come on this soon.

[timmyc]

Thanks for the update and your persistence on this one Josh! So guessing the working caching plugins all have invalidation setup on REST POST/PUT/DELETE actions?

[joshuatf]

@timmyc Most of them don't distinguish at all between admin/non-admin/REST requests, which I think should be the case. It may be more overhead to watch for updated options in non-admin areas, but if a store has any methods which may update options via the front-end this should still invalidate cache.

If we want to limit "exposure" for performance reasons, I think that limiting to admin requests and POST/PUT/DELETE requests is a good strategy. Though I would be a little surprised if the update_option hook was having any significant impact on performance.

[joshuatf]

After being able to recreate this issue every time on Pressable, today I am no longer able to. Spun up a new Pressable site and things worked as expected with settings persisting on refresh without any need to flush the object cache. The same is true of an Atomic dev site.

I returned to my previously created site and using the same WC and WC admin versions where this bug was present and was not able to recreate the issue there either.

@pmcpinto Can you check to see if you're still hitting the issue you outlined in https://github.com/woocommerce/woocommerce-admin/issues/3151?

[pmcpinto]

@pmcpinto Can you check to see if you're still hitting the issue you outlined in #3151?

Hey @joshuatf I just tested it in a brand new store and I'm getting the automated taxes message, so it's working smoothly.

[psealock]

Lets close this one out for now.