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

[WordPress Trac]

#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 emilycestmoi):

 I've had this issue pop up in my error logs for some time now and finally
 spent 30 minutes or so debugging it today. This error is happening for me
 roughly every 30 minutes on a fairly high traffic site (3000 uniques per
 day) with DISABLE_WP_CRON = true and wp-cron.php being called */1 (every 1
 minute) from crond.

 The issue is as described in [#1]. The $cron data being set with
 update_option('cron', $cron) is the same as the value returned by
 get_option('cron'). This causes update_option('cron', $cron) to return
 false which is then interpreted as an error in _set_cron_array().

 From option.php:

 {{{
 /*
          * If the new and old values are the same, no need to update.
          *
          * Unserialized values will be adequate in most cases. If the
 unserialized
          * data differs, the (maybe) serialized data is checked to avoid
          * unnecessary database calls for otherwise identical object
 instances.
          *
          * See https://core.trac.wordpress.org/ticket/38903
          */
         if ( $value === $old_value || maybe_serialize( $value ) ===
 maybe_serialize( $old_value ) ) {
                 // XXX-THIS IS RETURNING FALSE
                 return false;
         }
 }}}

 It looks like the pull from [#1] (https://github.com/WordPress/wordpress-
 develop/pull/3726) will fix the issue, although I haven't tried it yet.
 There is no drawback of ignoring the error as it's simply discarding
 duplicate cron data, but I'm still unsure why get_option('cron') is
 actually returning the duplicate of what is attempting to be saved in some
 cases (my initial thought is caching and a race condition?)--this will
 take more time to investigate. For now I'm going to patch this on my site
 to stop the error from coming up when duplicate data is saved. I will
 investigate further when I have time.

 Hopefully the fix gets committed soon.

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