Document known workaround for alloptions race condition issue

[danielbachhuber]

From https://wordpress.org/support/topic/object-cache-out-of-sync-with-database/:

I have noticed due to user complaints that the object cache gets out-of-sync with the database. For example – WRT plugin activation/deactivation – I have users complained that a plugin cannot be activated. wp-admin shows plugin to be deactivated and activating plugin in wp-admin does nothing. I found it was due to the redis cache being out-of-sync with the database. Redis cache shows that the plugin was deactivated; but the database shows the plugin to be activated. Manually flushing the Redis cache (either the specific key or entire cache) would “fix” the situation.

This is a known issue: https://core.trac.wordpress.org/ticket/31245

Previously #157
However, there's a workaround we could document: https://core.trac.wordpress.org/ticket/31245#comment:57

[mfs-mc]

Is this still an issue? This WP Core threads reads like this was fixed in 5.3.1. Yes? No? But perhaps there are still Pantheon-specific issues?

https://core.trac.wordpress.org/ticket/31245#comment:96

https://core.trac.wordpress.org/ticket/31245

I'm reviewing some older code that use something like

wp_cache_delete('alloptions', 'options');

And that's running on a cron set to - I believe - every minute. The delete + recache every minute isn't going to buy us much.

[danielbachhuber]

Is this still an issue?

I'm not sure, to be honest. I haven't heard any reports of it recently, but I'm also not working across as large a number of sites these days.

This WP Core threads reads like this was fixed in 5.3.1. Yes? No?

It was partially mitigated in core, but not fixed fully.

But perhaps there are still Pantheon-specific issues?

Not quite Pantheon-specific, but specific to any site using a Redis or Memcache-based persistent object cache (unless the implementation had specific mitigation).

[mfs-mc]

@danielbachhuber - Thanks for the update / input. I'll just assume it's still an issue, unless I somehow find out otherwise.

p.s. I know it's not wholely your baby at this point but while I have your attention I wanted to say thanks for all your wp-cli work <3

[danielbachhuber]

You're welcome! 😄

[mfs-mc]

@danielbachhuber - Mind if I ask a quick question? Please? Is this issue limited to Redis and wp options where autoload is true? Or Redis and all wp options? tia

[danielbachhuber]

@mfs-mc It looks like non-autoloaded options are cached individually:

This would mean you'd avoid the alloptions race condition where a thread writing Option A could accidentally the cache value for Option B.