[wp-trac] [WordPress Trac] #27669: Stale `db_version` value after update with external object cache

[WordPress Trac]

#27669: Stale `db_version` value after update with external object cache
-----------------------------+-----------------------------
 Reporter:  johnbillion      |       Owner:
     Type:  defect (bug)     |      Status:  reopened
 Priority:  normal           |   Milestone:  Future Release
Component:  Upgrade/Install  |     Version:  3.9
 Severity:  critical         |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------------

Comment (by rmccue):

 I suspect this could be #31245. @willmot mentioned we haven't hit it on
 Human Made stuff, and I'd guess that's because we're running
 [https://core.trac.wordpress.org/ticket/31245#comment:7 a modified
 version] of the Memcache plugin.

 It's somewhat trivial to cause:
 * WP runs a HTTP request to itself to update the DB on autoupgrades.
 * A plugin adds a hook to `shutdown` or similar which calls
 `update_option` or similar
 * HTTP request closes (`fastcgi_finish_request` or similar in the shutdown
 hook), and WP flushes the cache
 * The race condition causes the plugin to call `update_option`, which
 overwrites `alloptions`

 The key to causing it here is `fastcgi_finish_request` though, which
 causes the process to continue running after the request has finished.
 There's other ways to cause it though, things like TLC Transients can also
 cause it by spawning a grandchild process that does the same.

 Occam's Razor indicates that this might not be the case, as it's somewhat
 complex to cause, ''but'' the fact we've not hit it on HM stuff, and that
 we already have `wp_cache_delete( 'alloptions', 'options' )` to mitigate
 #31245 is evidence in favour of this theory.

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