[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 j3gaming):

 Replying to [comment:56 domainsupport]:
 > Replying to [comment:54 emilycestmoi]:
 > > Ok, I can confirm that the issue is due to the cron option_value being
 updated to the identical value that already exists in the database. That
 when the query runs:
 > >
 > >
 > > {{{
 > > UPDATE `wp_options` SET `option_value` = serialized_data WHERE
 `option_name` = 'cron'
 > > }}}
 > >
 > > Rows matches: 1 but Changed: 0.
 > >
 > > This is why mysqli_affected_rows() returns 0 which triggers the whole
 error.
 > >
 > > I can see in my logs that a query with an UPDATE is ran with
 serialized_data (and it succeeds) just before the UPDATE that fails with
 the identical serialized_data.
 > >
 > > So the question is, can we safely ignore this error or do we need to
 have additional locking to prevent the query from running twice with the
 same serialized_data (or to reload the cron wp_options data before
 saving)?
 >
 > Further to @j3gaming reply ... if you are seeing multiple `UPDATE`
 commands for the same serialised data when the `cron` option is updated
 then the queries are being run within the same second since the key to the
 serialised data is a unix timestamp.
 >
 > Furthermore, as @j3gaming mentions, the lock that cron uses (also saved
 in the same `wp_options` table as a transient) is a `microtome()`
 timestamp so in order for there to be a race condition, either the two
 cron events would have to fire fast enough to not have enough time to save
 the first transient to the database or they would have to fire in exactly
 the same microsecond (unlikely).
 >
 > How are you firing cron events and if via the system cron (rather than
 relying on the default requests to the server method) have you disabled
 the default cron by adding `define( 'DISABLE_W_CRON', true);` to `wp-
 config.php`?
 >
 > The only other thing I want to mention here is to pose a question ... if
 `$wpdb` thought that the `UPDATE` query had failed (for whatever reason)
 would it attempt to retry? And if the original query had actually not
 failed and instead both queries were successful could this be a situation
 that was occurring?
 >
 > Oliver

 I posted my logging code, and the output of the logs on the other ticket:
 https://core.trac.wordpress.org/ticket/57924#comment:15

 I was able to get an output of 2 distinct, but very close microtimes.

 Not using the system cron, it is disabled in wp-config. On linux, I'm
 using the OS cron:
 https://core.trac.wordpress.org/ticket/57924#comment:17

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