[wp-trac] [WordPress Trac] #63450: Race condition for transient with no expiration and object cache active

[WordPress Trac]

#63450: Race condition for transient with no expiration and object cache active
--------------------------+-----------------------------
 Reporter:  hugod         |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Cache API     |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 When object cache is installed and is temporarily unavailable, transient
 values with no expiration can be obsolete.

 Here is a scenario:
 - No object cache active, do `set_transient( 'foo', 'bar' );`
 - Now activate object cache
 - Do `delete_transient( 'foo' );`, `foo` is deleted from the cache but not
 from `wp_options` table ([see]https://github.com/WordPress/wordpress-
 develop/blob/24dde230694b33c43c3b5e9ce87320f19d08da96/src/wp-
 includes/option.php#L1394)
 - For some reason, the transient value must change, do `set_transient(
 'foo', 'baz' );`. The new value is correct in cache, but not in
 `wp_options` table ([see]https://github.com/WordPress/wordpress-
 develop/blob/24dde230694b33c43c3b5e9ce87320f19d08da96/src/wp-
 includes/option.php#L1542).
 - Now let's say the cache is temporarily unavailable (update, malfunction,
 you name it). When doing `get_transient( 'foo' );` we get `'bar'` instead
 of `'baz'` (we expect the last value set).

 If some major feature depends on this transient (e.g. rewrite rules), it
 can lead to weird behaviors that are hard to debug.
 For the record, we encountered such a bug in Polylang
 ([see]https://github.com/polylang/polylang/pull/1653).

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