-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
fix(BackgroundJob): Add time leeway in start condition in TimedJob #50868
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
base: master
Are you sure you want to change the base?
fix(BackgroundJob): Add time leeway in start condition in TimedJob #50868
Conversation
Since cron jobs may not always run at the very same second, e.g. at 10:45:16 and at 10:50:14, some jobs (depending on the interval) that should actually run wouldn't be started when exactly comparing the interval with the time of the last run. Therefore, allow a time leeway of a few seconds. Signed-off-by: Matthias Meusburger <matthias.meusburger@gmx.at>
/backport to stable31 |
/backport to stable30 |
/backport to stable29 |
/backport to stable28 |
Still not optimal. If a job that is executed before the critical one took a long time during the last cron run (e.g. UpdateAvailableNotifications), the critical one could still be skipped on the next run. |
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Summary
Since cron jobs may not always run at the very same second (observed in web hosting environment), e.g. at 10:45:16 and at 10:50:14, some jobs (depending on the interval) that should actually run wouldn't be started when exactly comparing the interval with the time of the last run. Therefore, a time leeway of a few seconds should be allowed.
Checklist
Screenshots before/after for front-end changes