Closed daichi5 closed 3 months ago
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 job:
section is redundant and unnecessary, and was not the result of anything intentional. The @job
ivar is simply there to support memoization of the instance of the payload class, which we delegate method calls to so that API methods like max_run_time
and max_attempts
are honored by ActiveJob-executed jobs.
Circling back! This behavior should be changed in the 0.5.0
release now.
@smudge
Hi, I have checked the recent 0.5.0
update.
Although undefined jobs are now retried, the rescheduling does not seem to be working properly for undefined jobs as a NameError is generated when job.max_attempts
is referenced.
As a result, attempts
value is not incremented and the job is retried indefinitely. Could you please check this?
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. (InDelayedJob
, 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?