-
-
Notifications
You must be signed in to change notification settings - Fork 210
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
Adds the ability to delete jobs on the dashboard; add cleanup_discarded_jobs
option to retain discarded jobs during cleanup
#597
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TAGraves This is fantastic! Thank you for adding this feature and extending the dashboard 🙌
Two things:
ActiveJobJob#destroy
needs to be re-defined on the ActiveJobJob model because the native Rails#destroy
method won't destroy the entire set of executions that make up the job (it will only destroy the HEAD execution, which then will make the HEAD~1 execution become the new HEAD of the Job). I've been kicking that problem down the road myself. There should be a#destroy_job
method that locks the job and then destroys all of the executions that make up the job.- I think the naming should be consistent with Rails conventions and it should be "destroy job" rather than "delete".
I really appreciate the contribution (this is like 95% there) and I can help make those other changes to push it over the finish line.
@bensheldon Regarding the first point,
Adding some logging, this is the SQL that is execution when running
I think this is because the primary key is defined as active_job_id. I think it's still fine to manually define it though to keep it consistent with the other operations in active_job_job.rb. I'm more than happy to make the changes you mentioned to push it over the finish line! |
@TAGraves Ooh, that's nice that Rails handles destroy with the explicit primary_key. TIL. I do think there should be an explicit Thought: are there limitations on what job states should be destroyable? Eg we shouldn't destroy a running job. Thinking aloud: should a job have to be discarded before it is destroyable? |
I think it's pretty reasonable to make only discarded jobs destroyable. I'll make these changes. |
@bensheldon I've added the |
cleanup_discarded_jobs
option to retain discarded jobs during cleanup
@TAGraves thank you! This looks great 🎉 In terms of release orchestration, I'm going to merge in #575 first, then I will fix conflicts and get this PR merged. I also intend to remove the ability to delete an individual execution. Now that whole jobs can be deleted, I don't think it makes sense to allow removal individual executions. I'll do that as a separate PR just to expedite getting this one released. |
# Conflicts: # engine/app/views/good_job/executions/_table.erb
Quick question, where can I find documentation or an example for destroy_job and finding scheduled jobs? - what I'm trying to do is to find a specific scheduled job and cancel it (from the command line). |
@rgaufman jobs = GoodJob::ActiveJobJob.where(scheduled_at: 30.minutes.ago...Time.current)
jobs.each(&:destroy_job) Edit: you can find existing scopes here: good_job/lib/good_job/active_job_job.rb Lines 34 to 61 in c8f19ee
|
Right now the only way to delete a job is to use the cleanup command. We have workflows that involve deleting jobs on an ad-hoc basis. For example, if a job fails for a reason that means that it can never be successfully retried, we want to delete that job so that it does not clutter up our discarded jobs page. The first commit in this PR adds the ability to delete any job in the dashboard (by calling
destroy
on the job).Additionally, we do not want discarded jobs to ever be deleted automatically. In some cases we may have a failed job from a week ago that we wish to preserve so that we can easily retry it after we release a fix for the issue. In other words, we always want to manually handle discarded jobs, either by retrying them or by deleting them -- we never want them cleaned up automatically. So the second commit adds a configuration option to only delete finished but undiscarded jobs via the cleanup command. This option is set to delete discarded jobs by default for now, so that this does not become a breaking change, but I would recommend flipping this default with the 3.0 release.
I believe this takes care of #594.