[wp-trac] [WordPress Trac] #61296: Add "force" parameter to get_option and get_transient

[WordPress Trac]

#61296: Add "force" parameter to get_option and get_transient
-----------------------------------------+------------------------------
 Reporter:  juvodesign                   |       Owner:  (none)
     Type:  enhancement                  |      Status:  reopened
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Options, Meta APIs           |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+------------------------------

Comment (by juvodesign):

 > This sounds like a bug. If you can reproduce it reliably please post the
 exact steps.

 I am not sure if this is a bug, but the same race time issue we are
 discussing here.
 In my scenario B has already fetched the transients at the start of the
 action, which means the result is fetched and stored by the options usage
 of wp_cache_add: https://github.com/JUVOJustin/wordpress-
 develop/blob/769f0170f87acc22dca0289a042ae55148c3a35a/src/wp-
 includes/option.php#L202

 This situation gets worse when you have really long-running processes like
 an importer. The in-memory cache without directly calling wp_cache_get("",
 "", true) will very likely be stale at some point. This happened to me,
 and I had to create an ugly wrapper around get_transient that basically
 just deletes the object cache before querying the transient:

 {{{#!php
 <?php
 if (!wp_using_ext_object_cache()) {

     // Delete transient cache
     $deletion_key = '_transient_' . $key;
     wp_cache_delete($deletion_key, 'options');

     // Delete timeout cache
     $deletion_key = '_transient_timeout_' . $key;
     wp_cache_delete($deletion_key, 'options');

     // At this point object cache is cleared and can be requested again
     $data = get_transient($key);
 } else {
     $data = wp_cache_get($key, "transient", true);
 }

 return $data;
 }}}

 > Frankly I'm not sure if there can ever be 100% guarantee that B will get
 the data set by A. My guess would be that if both A and B are part of the
 same WP install, using external memory cache (memcache?) would be the best
 option and would get as close to the 100% as possible.

 I have included my issue link regarding Redis as an external cache in the
 Trac ticket. This was actually my initial motivation for creating the
 ticket. I agree that an external cache can mitigate this issue to some
 extent. However, particularly for transients, the absence of a 'force'
 parameter leads developers to use wp_cache_get($key, "transient", true)
 instead of the transient API.

 My personal opinion is that developers using the transient API shouldn't
 need to worry about whether an external cache is being used or not. The
 API should serve as a cache-agnostic way to interact with this specific
 part of the WordPress core.

 Since transients are described as "using the wp_options database table to
 temporarily store cached information." in the docs, I think there should
 be a way to actually enforce getting the latest version of the "cached
 information" backed into its API.

 I could definitely see cases as described in the other tickets, where the
 same is happening with options itself. To fix this for transients, there
 is no need to tackle alloptions as transients are never stored as autoload
 options if I am not mistaken. Nonetheless, the provided patch looks good
 to me, and maybe we could incorporate it? Is this something it should or
 could do? Will the initial reporter of
 https://core.trac.wordpress.org/changeset/46780 still be acknowledged?

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