WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#15014 closed defect (bug) (maybelater)

Cron : ONE scheduled hook may be executed several times

Reported by: arena Owned by:
Milestone: Priority: normal
Severity: major Version:
Component: Cron API Keywords:
Focuses: Cc:

Description

As shown in the attached logs

wp_cron_v0 : log as produced
wp_cron : reordered by hooks

scheduling ONE hook can result in MULTIPLE executions

Attachments (2)

wp_cron_v0.txt (72.1 KB) - added by arena 4 years ago.
genuine log
wp_cron.txt (72.1 KB) - added by arena 4 years ago.
hook reordered log

Download all attachments as: .zip

Change History (9)

arena4 years ago

genuine log

arena4 years ago

hook reordered log

comment:1 follow-up: Denis-de-Bernardy4 years ago

  • Keywords reporter-feedback added

Might it be that you're registering the cron job multiple times, as in without checking that it's already registered?

comment:2 in reply to: ↑ 1 arena4 years ago

Replying to Denis-de-Bernardy:

Might it be that you're registering the cron job multiple times, as in without checking that it's already registered?

@Denis-de-Bernardy, no, i am sure each (hook/parms) is scheduled once !

comment:3 arena3 years ago

  • Keywords reporter-feedback removed

comment:4 follow-up: nacin3 years ago

  • Keywords reporter-feedback added

We need more information here.

Race conditions in the cron API are very rare. Chances are your code is wrong.

comment:5 in reply to: ↑ 4 arena3 years ago

Replying to nacin:

We need more information here.

Race conditions in the cron API are very rare. Chances are your code is wrong.

see #13158

"The root problem is that we store the cron data in an array. A naive get, process, set algorithm will always be prone to race conditions.

We can rework those scheduling functions to move as much of the processing before the get so that there's less time between the get and the set, but that won't solve the problem. Most of the bottleneck is probably in the db write, so reducing the time spent in PHP between get and set probably won't help that much.

We could try putting in some locking (in the application layer) and maybe making a queue of stuff that needs to be added (one per row or we're back to where we started... transients?), but I don't think that will guarantee we prevent the race condition. More complicated and easy to just move the race condition from one area to another.
"

comment:6 arena3 years ago

  • Keywords reporter-feedback removed

comment:7 westi3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

The only way we are going to reduce the window for the race condition is to completely rework how cron works.

We have no plans to do that at present.

Note: See TracTickets for help on using tickets.