Behavior of retried jobs

[salmonsteak1]

I just came across this issue #78 as I was confused by the behavior of failed jobs in mission control and decided to search for related issues.

Right now, it seems like jobs that are using the retry_on mechanism by active job would generate multiple entries under "finished job", with the final failed attempt under "failed jobs". Since they all have the same active job ID, they would point to the same entry under the hood.

I was just wondering if that's really the intended case as I was initially under the impression that my failed job was somehow being completed successfully since it was under the "finished jobs" tab too.

[rosa]

Hey @salmonsteak1, for Solid Queue, yes, that's the intended behaviour because it's what Active Job does when it retries a job automatically: it just enqueues it again with the same Job ID.

We could show this more clearly in Mission Control, though 🤔 Perhaps adding some more prominent indication that the finished job has been retried? However, I'm not sure if it's possible to know when a job has been retried and has finished fine because the exception raised has been handled by Active Job, or if it has actually finished for real. All this happens outside Solid Queue. Resque handles this differently because it doesn't keep finished jobs around, it just deletes jobs when picking them up from the queue, so this doesn't happen.

[dgmora]

Maybe this could be done in the Scheduled Jobs list and in the view? It would be nice to see if the job is a retry or not. The number of executions could also be shown outside of the raw data.

[rosa]

Thanks @dgmora! I think the scheduled jobs view wouldn't work because these are jobs that haven't run yet, whereas retries are finished jobs. I think it should need to be in the individual job view 🤔 As for the number of executions, there's a PR for that: #204. I haven't concluded it's correct yet so I haven't merged it, but it'll be there eventually.

[dgmora]

I think my terminology wasn't right, I was referring to "reexecutions" in case a job finishes with an exception 🙂. I've made a PR with some examples: #225