[wp-trac] [WordPress Trac] #28664: wp_load_alloptions() fails to set object cache when persistent alloptions cache is "0"

[WordPress Trac]

#28664: wp_load_alloptions() fails to set object cache when persistent alloptions
cache is "0"
-----------------------------+-----------------------------
 Reporter:  danielbachhuber  |      Owner:
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Cache API        |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 When alloptions persistent object cache is set to `0`,
 `wp_load_alloptions()` fails to reset it with appropriate values. This
 results in every use of `get_option()` to produce the load alloptions
 query `SELECT option_name, option_value FROM wp_options WHERE autoload =
 'yes'` because the object cache never gets appropriately populated.
 Specifically, `wp_cache_add()`won't set the alloptions value when it's
 already seen to be set.

 The end result is a massive impact on site performance when the object
 cache backend failboats. I'd expect WordPress to handle this scenario a
 bit more gracefully, possibly falling back to its internal object cache if
 it detects failures with the persistent object cache. However, it's
 debatable as to whether the solution lies within a drop-in, or whether
 it's the responsibility of core.

 `wp_cache_add()` is used over `wp_cache_set()` for performance reasons
 with *external* object caches — it doesn't matter one way or another for
 the internal object cache (genesis #4138). One option is to distinguish
 between them, and offer different behaviors. However, the most technically
 appropriate solution is likely to check that the data coming from
 `wp_cache_get()` is as expected.

 To answer your question before you ask it, I'm not sure how the Memcached
 persistent object cache value gets set to zero. It seems to come and go,
 sometimes occurring regularly when I restart Memcached, and I've seen the
 issue reproduce with both Ryan Boren's and Zack Tollman's drop-ins
 (meaning real bug is most likely outside of WordPress).

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28664>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform