[wp-trac] [WordPress Trac] #49520: Feature request: Migrate cron from a single serialized wp_options entry to its own table

[WordPress Trac]

#49520: Feature request: Migrate cron from a single serialized wp_options entry to
its own table
--------------------------+------------------------------
 Reporter:  archon810     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cron API      |     Version:  5.3.2
 Severity:  major         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by SergeyBiryukov:

Old description:

> For as long as I can remember using WordPress, its Achilles heel has been
> cron.
>
> `cron` is a single serialized entry in `wp_options`, and on busy sites is
> subject to race conditions that oftentimes continuously overwrite the
> `cron` value with outdated data, resulting in:
>
> 1. completed events coming back (and thus running more than once)
> 2. arguably worse, `schedule_single_event()` losing events because
> they're overwritten
>
> The latter specifically has long been responsible for the infamous
> "missed schedule" issue in WordPress - a critical functionality of
> publishing posts at a certain time being completely unreliable.
>
> https://core.trac.wordpress.org/ticket/39924
> https://core.trac.wordpress.org/ticket/41965
> etc.
>
> https://github.com/humanmade/Cavalcade needed to be created to properly
> resolve this, but it's a 3rd party solution that isn't as trivial to set
> up as activating a plugin, and shouldn't be necessary in well-designed
> software. I see the cron problem as WordPress's biggest and most glaring
> flaw, and I'm sure many would agree.
>
> So, what's the solution? Can cron be migrated into its own wp_cron table
> and the related functions made to interact with the migrated data
> transparently to the user? I know it'd be a pretty big project, but it's
> one of those bandaids that just needs to be finally ripped off.
>
> https://core.trac.wordpress.org/ticket/15148 was closed as `wontfix`, but
> I hope the team can reconsider.
>
> Thank you.

New description:

 For as long as I can remember using WordPress, its Achilles heel has been
 cron.

 `cron` is a single serialized entry in `wp_options`, and on busy sites is
 subject to race conditions that oftentimes continuously overwrite the
 `cron` value with outdated data, resulting in:

 1. completed events coming back (and thus running more than once)
 2. arguably worse, `schedule_single_event()` losing events because they're
 overwritten

 The latter specifically has long been responsible for the infamous "missed
 schedule" issue in WordPress - a critical functionality of publishing
 posts at a certain time being completely unreliable.

 #39924, #41965, etc.

 https://github.com/humanmade/Cavalcade needed to be created to properly
 resolve this, but it's a 3rd party solution that isn't as trivial to set
 up as activating a plugin, and shouldn't be necessary in well-designed
 software. I see the cron problem as WordPress's biggest and most glaring
 flaw, and I'm sure many would agree.

 So, what's the solution? Can cron be migrated into its own wp_cron table
 and the related functions made to interact with the migrated data
 transparently to the user? I know it'd be a pretty big project, but it's
 one of those bandaids that just needs to be finally ripped off.

 #15148 was closed as `wontfix`, but I hope the team can reconsider.

 Thank you.

--

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