-
Notifications
You must be signed in to change notification settings - Fork 8
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
Difference in error behavior when a job is undefined #23
Comments
I thought one solution would be to not include the job key in the handler column. What do you think?👀 |
Hi @daichi5! Thanks for the report, and good catch! You're spot on -- that |
Circling back! This behavior should be changed in the |
@smudge Although undefined jobs are now retried, the rescheduling does not seem to be working properly for undefined jobs as a NameError is generated when As a result, |
This ensures that exceptions raised in thread callback hooks are rescued and properly mark jobs as failed. Fixes Betterment#23 and Betterment#41
Hi! We have migrated
DelayedJob
toDelayed
and are running it.While observing the worker, we came across an error and found a difference in behavior.
Here is the stack trace in the
last_error
column.This error occurs when a job is enqueued even though the class definition of the job does not exist in the worker.
(For example, this can occur when adding a new job definition and trying to synchronize the webapp, worker Deployment with ArgoCD.)
I noticed that some kind of error occurs when executing a job, whether it is a
DelayedJob
orDelayed
, but the difference is thatDelayed
does not retry and the failed_at column is updated.The situation of enqueuing a non-existent job is not good, but we expect the worker to retry and complete the job execution once the code is up-to-date.
I am assuming that this difference in behavior exists because of the difference in serialization and deserialization of jobs.
In the case of
Delayed
, thejob
key is added to the serialization string of the job, and an error seems to occur when deserializing it.DeserializationError
is handled so that it is not retried.(In
DelayedJob
, there is nojob
key and no error occurs during deserialization.)I assume that the job can be executed even if this job key does not exist.
Is there any intention behind this difference in specifications?
The text was updated successfully, but these errors were encountered: