[wp-trac] [WordPress Trac] #57271: Cron unschedule / reschedule event errors

WordPress Trac noreply at wordpress.org
Sun Mar 5 08:48:04 UTC 2023


#57271: Cron unschedule / reschedule event errors
----------------------------------------+------------------------------
 Reporter:  domainsupport               |       Owner:  audrasjb
     Type:  defect (bug)                |      Status:  assigned
 Priority:  normal                      |   Milestone:  Awaiting Review
Component:  Cron API                    |     Version:  6.0
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------------------

Comment (by domainsupport):

 @peterwilsoncc I'm confident that I now know what's causing this.

 After the comment from @j3gaming, I modified line 520 of `/wp-
 includes/option.php` as follows ...

 {{{#!php
 <?php
         $result = $wpdb->update( $wpdb->options, $update_args, array(
 'option_name' => $option ) );
         if ( ! $result ) {
 if ('cron' === $option) { error_log('Cron failed to save to the
 database'); }
                 return false;
         }
 }}}

 Then I waited for the next `could_not_set` error notice and sure enough
 ...

 > [05-Mar-2023 01:01:02 UTC] Cron failed to save to the database
 > [05-Mar-2023 01:01:02 UTC] Cron reschedule event error for hook:
 wf_scan_monitor, Error code: could_not_set, Error message: The cron event
 list could not be saved., Data:
 {"schedule":"wf_scan_monitor_interval","args":[],"interval":60}

 So this confirms that the issue occurs when (for whatever reason)
 `update_option()` is unable to save to the database.

 This makes me immediately ask two questions ...

 1. What mechanism exists whereby if `$wpdb->update()` fails in
 `update_option()`, the request is saved (maybe as .json to the file
 system) until such time as the issue with the database has been resolved
 and the `$wpdb->update()` failures can be re-run or does this need to be
 developed?
 2. What other `update_option()` failures are going un-recorded?!

 If the answer to 2. is unknown then I think this ticket's severity needs
 to be upgraded to "major" because it would mean that swathes of
 `update_option()` requests could be (and probably are) going silently
 uncompleted if there is a glitch with the database.

 Oliver

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


More information about the wp-trac mailing list