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

Clear old jobs while loading the jobs from schedule #405

Merged
merged 3 commits into from
Mar 3, 2023

Conversation

sandip-mane
Copy link
Contributor

Patch for #396

@sandip-mane
Copy link
Contributor Author

@markets I was not able to quickly update PR #396, hence created a new one. Please review.

@markets
Copy link
Member

markets commented Mar 3, 2023

Thanks @sandip-mane! Maybe we should update some tests too? I think the related tests are still using the non-bang version.

Comment on lines +1276 to +1280
out = Sidekiq::Cron::Job.load_from_hash! @jobs_hash
assert_equal out.size, 0, "should have no errors"
assert_equal Sidekiq::Cron::Job.all.size, 2, "Should have 2 jobs after load"

out_2 = Sidekiq::Cron::Job.load_from_hash @jobs_hash
out_2 = Sidekiq::Cron::Job.load_from_hash! @jobs_hash
Copy link
Member

@markets markets Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was referring the ScheduleLoader tests: https://github.com/sidekiq-cron/sidekiq-cron/blob/master/test/unit/schedule_loader_test.rb. Not sure if those should be updated too 🤔.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, seemed like the right thing to do. Have updated the tests.

@codecov
Copy link

codecov bot commented Mar 3, 2023

Codecov Report

❗ No coverage uploaded for pull request base (master@e01b653). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #405   +/-   ##
=========================================
  Coverage          ?   93.36%           
=========================================
  Files             ?       10           
  Lines             ?      482           
  Branches          ?        0           
=========================================
  Hits              ?      450           
  Misses            ?       32           
  Partials          ?        0           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@markets markets merged commit 48c2563 into sidekiq-cron:master Mar 3, 2023
@fabn
Copy link

fabn commented May 25, 2023

This should have been a breaking change, I used to create some cronjobs programmatically and they are gone on every restart.

Copy link

@rchasman rchasman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR introduced a massive issue for us, where it destroys existing jobs when we deploy.
We only load some of our schedules from a YAML, because of this, the ones that are dynamically created and stored in Redis are cleared.

@sandip-mane
Copy link
Contributor Author

@markets shall we revert this change? The issue with dynamic cron jobs will continue to be an issue on every deploy IMO.
But it also leads to another issue where if I modify the class for an existing cron job, then I have to manually delete the old one using a script.

I think the best way would be to document the usage of dynamic cron jobs.

Thoughts?

@sandip-mane
Copy link
Contributor Author

We only load some of our schedules from a YAML, because of this, the ones that are dynamically created and stored in Redis are cleared.

@rchasman are all jobs from ScheduledSet cleared or only the Cron jobs are cleared?

@markets
Copy link
Member

markets commented Oct 20, 2023

hmm 🤔 maybe we should revert this change... It seems a good idea, but it seems it breaks with dynamic jobs, which is worst scenario compared to old jobs in the schedule (that can be cleaned manually).

Another idea (probably ideal solution?) is to only cleanup the ones defined in the YAML, but right now, we don't have a mechanism (an attribute or an extra data structure) to distinct between dynamic jobs vs static (defined in the YAML).

So yes, maybe it's better to revert it and document it?

@sandip-mane
Copy link
Contributor Author

My honest opinion:
Cron schedule should be kept up to date upon every deployment. (For various reasons, for example, I rename an existing cronjob class, delete a cron-job etc)
This creates an issue with dynamic cron jobs, so they need to be handled separately. I have not worked on these yet so not sure what could be the best way to deal with them.
Probably having an attribute for dynamic jobs could help distinguish between the jobs and we will be able to handle it from the gem.

I feel this should be the plan:

  1. Revert & release
  2. Have a way to distinguish dynamic crons
  3. Add this change back (it should only clear non-dynamic crons)

@markets
Copy link
Member

markets commented Oct 20, 2023

Agree with the plan! Please, feel free to send PRs to move this forward, unfortunately I've very limited time at this point to work on these changes.

@markets
Copy link
Member

markets commented Oct 23, 2023

hey @sandip-mane 👋🏼 I already merged the revert, but before pushing a new release I think it would be better to have the "dynamic crons" thing (points 2 and 3 of the plan). This way, we'll publish a much more solid release. If we release only the revert, the original issues may arise again... What do you think?

@sandip-mane
Copy link
Contributor Author

Sure sure, I will try to send PRs for the other 2 issues by this weekend (Working on a release towards a deadline).

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.

4 participants