Replies: 1 comment
-
|
Interesting proposal. I will talk to @merencia and see if it's feasible. I don't know what your job is doing, but if it has iterations, maybe you could break it into smaller jobs? Anyway, we will talk about it. Having the feature of "progress" is indeed interesting. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I like the timeout mechanism for detecting stale jobs. However I have long running jobs thus requiring a high timeout. I would like to keep timeout low in order to quickly determine stale jobs. I was thinking that for long running jobs they should be able to report their progress and reset the timestamp used for determining if a job is stale.
e.g I could have a very long running job 1hr+ but with a timeout / stale detection of it not making any progress within a 5 minute window.
This all sort of hinges on the assumption of a job being in a stuck in an
activestate but not actually executing. e.g ungraceful shutdown or bad error handling.Was thinking maybe there could be a new abstract timestamp on the job that could be used solely for the purpose of determining if a job is stale. With a new job method that'd re-set this timestamp each time it was called. I was thinking something like
progressed_atwhere initially it'd be set viaattempted_at/claimed_atTimestamp then continuously set to the current date each time the job reports progress via a convenience method on the job instance class. e.greportProgress()Additionally the reportProgress method could update arbitrary metadata on the job itself that may be useful in determining progress or useful if the job is re-attempted.
Backend implementations could then determine if jobs are stale via the following logic.
Date.now() > job.progressed_at + job.timeoutWonder what you think of this proposal? I can sort of see how it could be implemented without adding a new field, by re-using the
attemped_attimestamp. But I think this might be less than ideal as you'd loose visibility of when the job execution started.Beta Was this translation helpful? Give feedback.
All reactions