Skip to content
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

Fix cron jobs timing #463

Merged
merged 2 commits into from
May 16, 2024
Merged

Conversation

afrase
Copy link
Contributor

@afrase afrase commented Mar 7, 2024

Hey folks!

So I recently had some free time and decided to revisit this issue I had previously fixed at the company I was working for back in 2019.

I moved the calculation method into the Utils module to make testing easier and added lots of comments explaining what was going on. Added tests for the method since testing this issue through Rufus is incredibly difficult.

Sorry @marcelolx for never getting back to you on this.

This would close #396 #276 and #455

This change improves the job enqueue logic specifically for CronJobs. Instead of using the current time for job queuing, it tries to calculates the actual scheduled time. This prevents potential issues where the job could be queued multiple times due to a delay in job execution. It also includes tests for the new run time calculation logic.
lib/sidekiq-scheduler/utils.rb Outdated Show resolved Hide resolved
@afrase afrase mentioned this pull request Mar 7, 2024
@marcelolx
Copy link
Member

Thanks for putting this together @afrase! I had a stab at this in #396 but never did get back to it

I will set some time aside to look into the comments you left in the code 🙏 Looking forward to incorporate this

When a job is scheduled exactly between next and previous runs then round down to the previous run time.
Updated specs to reflect this.
@marcelolx marcelolx merged commit 9da5f13 into sidekiq-scheduler:master May 16, 2024
20 checks passed
@michelson
Copy link

Is this a fix for jobs running multiple times if we use multiple machines?

@marcelolx
Copy link
Member

Yeah, it will solve most of the cases (see #181) — there might be some edge cases it might not though, and would require some locking mechanisms #332 (comment)

@michelson
Copy link

Hi @marcelolx, Thanks for your reply. Could you go ahead and outline which edge cases you mentioned? I'm on the verge of deploying this and want to be 100% sure I'm doing things correctly. I will be running a 15-minute cron job.
I appreciate any help you can provide.

@marcelolx
Copy link
Member

I don't have a specific one, but essentially, since we don't use any global lock mechanism to push a job to Redis, there is always the possibility that two different hosts could push the same job at the same time. That though, became very unlikely with this change.

By global lock, I mean a lock that each host has to acquire to then push the job to the queue, something in similar to this #332 (comment)

@michelson
Copy link

michelson commented May 27, 2024

Hi @marcelolx , thanks for your reply. So I wonder, in an scenario where I have multiple sidekiq hosts but only have cron running on a single machine, should I worry about the message being executed multiple times by other hosts?

@marcelolx
Copy link
Member

@michelson no, no need to worry — if you run the scheduler on a single host it won't schedule it twice. With these changes here, it shouldn't run twice even if you run the scheduler on multiple hosts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants