[wp-trac] [WordPress Trac] #64950: wp_using_ext_object_cache can return null, causing type failures, potential fatals

[WordPress Trac]

#64950: wp_using_ext_object_cache can return null, causing type failures, potential
fatals
--------------------------+------------------------------
 Reporter:  ronalfy       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cache API     |     Version:  3.7
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------

Comment (by liaison):

 Technical context regarding the impact of return type consistency in
 wp_using_ext_object_cache()

 To provide more context on why ensuring a strict bool return type is
 critical, I've analyzed the primary callers of this function within
 WordPress Core. As a foundational "low-level switch," its return value
 dictates whether data flows to volatile memory or persistent external
 storage (e.g., Redis/Memcached).

 Key Callers and Scenarios:
 Bootstrapping Phase (wp_start_object_cache() in load.php):
 This is the most critical caller. It checks for object-cache.php. If
 detected, it calls wp_using_ext_object_cache( true ). If this switch is
 uninitialized or returns an ambiguous null during early loading, WordPress
 may default to the non-persistent internal implementation, bypassing the
 external cache entirely for early-loading logic.

 Transient API (set_site_transient() & get_transient() in option.php):
 The Transient API relies on this function to decide storage location.

 With External Cache: Data goes to wp_cache_set().

 Without External Cache: Data falls back to options or sitemeta database
 tables.

 The Risk: If an early call returns null (evaluated as false), the system
 might trigger redundant database I/O even when a high-performance cache is
 available.

 Multisite Context Switching (ms-settings.php):
 During switch_to_blog(), the core verifies if the current cache
 environment is persistent across the network. Drop-ins like Redis Object
 Cache often call this function to sync state during environment re-
 initialization.

 CLI and Compatibility Layers:
 Tools like WP-CLI and functions like wp_cache_flush_runtime() frequently
 trigger this function during simulated loading sequences to determine
 environmental capabilities.

 Why this matters: Eliminating the "Early-Loading Race Condition"
 Since wp_start_object_cache() is invoked at the very beginning of the
 WordPress lifecycle, any null leakage—especially when triggered by MU-
 Plugins or early db.php logic—creates a race condition where the system
 misidentifies the cache state.

 Ensuring a deterministic boolean return type eliminates this ambiguity at
 the foundational level of load.php.

 {{{#!th
 || '''Timeline''' || '''Event''' || '''Return Value (Current)''' ||
 '''Resulting Behavior''' ||
 || $T_1$ || `db.php` loads, queries cache state || `null` (evaluated as
 `false`) || Triggers slow DB-level fallbacks. ||
 || $T_2$ || `wp_start_object_cache()` runs || (Initializing...) || State
 is in transition. ||
 || $T_3$ || Initialization complete || `true` || Subsequent code follows
 the fast cache path. ||
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64950#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform