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.

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).

@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

You're welcome! 😄

@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

@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.