Skip to content

Cron may double schedule jobs in edge case #10279

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
scottsb opened this issue Jul 18, 2017 · 1 comment
Closed

Cron may double schedule jobs in edge case #10279

scottsb opened this issue Jul 18, 2017 · 1 comment
Labels
bug report Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed

Comments

@scottsb
Copy link
Member

scottsb commented Jul 18, 2017

Preconditions

Magento 2.1.3 (but I can see problem code has not changed in develop branch)

Steps to reproduce

These are a fairly artificial set of steps to reproduce the issue consistently, but the same situation can happen "in the wild" if the timings line up just right:

  1. Identify a cron job that takes a while to run (over a minute).
  2. Watch for selected job to run.
  3. While selected job is running, and during the same minute on the clock that original job was scheduled, flush cache and run cron again, forcing scheduler to run.

Expected result

When scheduler runs in step 3 above, it schedules a job for the next time increment beyond the cron run that is currently still in process.

Actual result

Instead, scheduler creates a pending job at the exact same time as the cron job that is in progress. Example result in the cron_schedule table:
screen shot 2017-07-18 at 11 24 24 am

Root cause analysis

The problem is that when ProcessCronQueueObserver::_generate() assembles the array of existing cron schedules that later will be skipped in saveSchedule(), it includes jobs only in pending status, not running status. At a minimum it should include running jobs as well, and I would probably argue it shouldn't pay attention to the status of the job at all: if a record for the job exists in cron_schedule for the given time, regardless of status, it shouldn't ever be rescheduled for the same time.

@magento-engcom-team magento-engcom-team added 2.1.x bug report Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed and removed G1 Passed labels Sep 5, 2017
@magento-engcom-team magento-engcom-team added the Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed label Sep 20, 2017
@magento-engcom-team
Copy link
Contributor

@scottsb thank you for your report.

Closed as duplicate #10650

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed
Projects
None yet
Development

No branches or pull requests

3 participants