[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:  needs-unit-tests needs-patch  |     Focuses:
------------------------------------------+------------------------------

Comment (by domainsupport):

 Replying to [comment:67 galbaras]:
 > My sites are not overloaded to the point of database choking, and WP
 Cron runs on a 15-minute schedule, so record locking is highly unlikely.
 Also, the recent surge in this occurrence may be related to changes in the
 (CloudLinux, PHP, WordPress, MySQL, Litespeed) software, rather than load
 or concurrency.

 Sounds to me like you have the same issue as @j3gaming which I mention in
 (1) ticket:57271#comment:66 whereby your cron is being fired in the same
 microsecond. This would also cause this scenario ...

 Replying to [comment:68 emilycestmoi]:
 > The update is run and rows matches: 1 but changed: 0. The reason is
 because the update statement is attempting to set the same serialized_data
 that is already set in the database. I have not found any cron events that
 have not been rescheduled or have been lost due to this warning, so for my
 case this warning can be safely ignored.

 ... because the WP cron event schedule being saved would be exactly the
 same. So it is my belief that in both of your cases that somehow WP cron
 is being fired more than once in the same microsecond causing a race
 condition.

 In my opinion the only way WP cron can fire more than once at the same
 time is if it is within the same microsecond (due to the transient lock).
 And, this would also cause the new serialised `cron` option to be
 identical resulting in the PHP error.

 In each of these cases I would recommend that you identify why / how WP
 cron is firing twice in the same microsecond and resolve because the issue
 would not be that WP cron events were being missed, but, inversely, they
 would actually be run twice because the `cron` option is only attempted to
 be saved ''after'' the events are run.

 So we have two distinct causes here ...

 1. Database issue preventing `update_option()` from being successful
 2. Race condition saving the same serialised data also preventing
 `update_option()` from being successful

 I am firmly in camp 1. You appear to be in camp 2. Both camps exist :)

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