Christian Fersch

I'm still waiting on @selwin to give some basic input on the design before I proceed.

> About the reenqueueing policy, I'd also suggest to make it a choice. In some cases, it would be interesting to reenqueue the job at the end of the origin...

Ah, but this is not meant to ever affect failed jobs. This is only for the worker beeing killed by external reasons, completely independent of the currently running job.

Hey @selwin, thanks for the response. Just to clarify: I would apply this feature *only* to controlled shutdowns of the worker. Not for unexpected deaths or failures of any sort....

Since you seemed sufficiently interested to warrant the effort I went ahead and ported the implementation in our project into the `python-rq` codebase and created #837. As mentioned there this...

Regarding hard shutdowns, It might make sense to handle them the same way. It is just a little bit dangerous, because if you have a c module that crashes the...

@guillemcabrera Are you doing it inside the job, or after the job has failed? If the job has already failed, you are probably looking for [requeue_job](https://github.com/nvie/rq/blob/master/rq/job.py#L64). After looking into this,...

@selwin You need to make a final decision on this. I made my case as well as I can :). I now also gave code that shows how it is...

@Jellybaby34 Do you have knowledge of the problem? Is it enough to check that the name is < 16 chars and does not contain `#`?

I linked the wrong thread. I meant this one: http://steamcommunity.com/app/211420/discussions/0/358415103477070691/