-
Notifications
You must be signed in to change notification settings - Fork 105
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
Jobs that eventually succeed will not queue downstream jobs #61
Comments
Hey @jdreic, thanks for the report. This sounds like a bug! |
Hi, The problem occurs in the job parameters. If you take look at https://github.com/chaps-io/gush/blob/master/lib/gush/worker.rb#L73, when children jobs are enqueued, it checks if parent has succeeded. This is my fix :
|
Hi, I prefer using refinements 😄 # Temporary fix: https://github.com/chaps-io/gush/issues/61
# Overrides Gush::Job start! method.
# Resets failed_at variable when Sidekiq reloads a job.
module GushJobFix
refine Gush::Job do
def start!
super
@failed_at = nil
end
end
end
class MyJob < Gush::Job
using GushJobFix
def perform
...
end
end |
Hey guys! Thank you for finding the culprit! Will release a fix ASAP! |
@mickael-palma-argus @theo-delaune-argus @jdreic this is now released as |
You rock 👍 |
When a job throws an exception, Gush marks it as failed and reraises the error. Job frameworks like Sidekiq retry failed jobs by default. When a job has failed but later succeeds, since Gush marked the job as failed from the first run, downstream jobs that depend on it won't run.
It would be great if there was an option to unset the failed status if a job re-runs, so that if it succeeds, the downstream workflow can continue.
The text was updated successfully, but these errors were encountered: