Since this is the method that officially schedules the job to be retried, it seems logical to me that this get set here.

The existence of this key in redis is how the custom failure backend knows a job is in the middle of a retry cycle and to *not* let it bubble up to the failed queue.  Since before this commit, that key is only set in the perform hook, any failure after forking but before perform is called will result in the job being retried *and* bubbling up to the failed queue.

*This* can happen at even a modest scale on Heroku, where dynos are cycled daily—it's pretty easy to get a SIGTERM during the call to `reconnect`.