[wp-trac] [WordPress Trac] #64080: WP_Upgrader doesn't release lock on create_lock

[WordPress Trac]

#64080: WP_Upgrader doesn't release lock on create_lock
-------------------------------+-----------------------
 Reporter:  skithund           |       Owner:  skithund
     Type:  defect (bug)       |      Status:  assigned
 Priority:  normal             |   Milestone:  6.9
Component:  Upgrade/Install    |     Version:  4.5
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+-----------------------
Changes (by skithund):

 * keywords:  has-patch has-unit-tests reporter-feedback => reporter-
               feedback


Comment:

 My reproduction code is failing due to 6.7 introducing `notoptions` cache
 in [58782]

 - `delete_option( 'lock.lock' );` sets `lock.lock` into `notoptions` cache
 in `delete_option()`.
 - `INSERT` inserts the option back, skipping caches, making `notoptions`
 cache stale.
 - `get_option( 'lock.lock' );` fails.

 But I'm having really hard time to figure out why our actual production
 code is failing, since it's not doing `delete_option( 'our_sync.lock' );`
 in any point. It has to be `notoptions` and persistent object caching, but
 how/why. My first hunch with `0 === wpdb::query()` was a red herring.

 Below is our production code stripped down with `run_our_sync` scheduled
 to be run hourly, using external cron and `DISABLE_WP_CRON` defined as
 `true`. We're running PHP 8.4, MariaDB 11.8 and Redis with `redis-cache`
 plugin.

 The following `wp_options` table row stayed in until I released the lock
 manually after ~48 hours.
 `(1418, 'our_sync.lock', '1759614618', 'off')`

 Timeline was that lock was created at 00:50:18, HTTP failed at 00:50:23,
 leaving a lock behind and every hourly try after that failed to create the
 lock (01:50:46, 02:50:42, 03:50:40 etc.).

 Should the component be changed to Cache API and version to 6.7?

 {{{#!php
 <?php
 add_action( 'run_our_sync', 'do_sync' );

 function do_sync() {
   require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader.php';

   error_log( 'Starting sync and creating lock' );

   if ( ! WP_Upgrader::create_lock( 'our_sync' ) ) {
     error_log( 'Failed to create lock' );

     return;
   }

   $response = wp_remote_get( 'https://example.org/data.json' );
   if ( is_wp_error( $response ) ) {
     error_log( 'HTTP request failed' );

     // Here we originally forgot to release lock, leaving a lock behind
 after a failed HTTP request.
     // WP_Upgrader::release_lock( 'our_sync' );

     return;
   }

   // Do stuff.

   WP_Upgrader::release_lock( 'our_sync' );
 }
 }}}

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