Selwin Ong

`job.meta` is actually used for storing non core RQ data. Storing `enqueue_at_front` attribute on the actual job hash is actually the correct way. If `job.enqueue_at_front` was not persisted correctly, you...

We haven't gotten around to implementing concurrent workers, unfortunately. This is something I'm keen to add, but never got around to it since it's going to be quite a big...

Yeah, this is because custom exception handlers are actually attached to the workers running jobs. When a worker is killed by the OS, it stops immediately without being able to...

RQ doesn't have this capability yet. Feel free to open a PR for this.

Since your load balancers are already redirecting traffic away from servers running old code versions, I think it makes sense to also stop RQ workers running on those servers and...

By "erroneous" circumstances, did you mean that jobs that don't finish successfully? Jobs should be killed if they run beyond their maximum timeout so in theory, worker keys should never...

Ah I see. Agree with your assessment, mind sending a PR with test? :) Sent from my phone > On Jan 27, 2015, at 12:40 AM, JamesHutchison [email protected] wrote: >...

I'm reopening this issue. I saw that you already attempted a fix for this [here](https://github.com/stevenkampen/rq/commit/57da38536a0dada048640c28e086519f2fd28a93). I think it's a good approach, just missing some tests. Please open a PR when...

[This PR](https://github.com/rq/rq/pull/1397) adds multi dependency feature to RQ proper. You should try this instead.

With the PR merged, you can do `queue.enqueue(my_func, depends_on=[job_1, job_2])`