I think you have to periodically call heartbeat function for this job.

@nvonpentz - @moteus is right that the best thing to do is to periodically call job.heartbeat() to retain the lock on the job. Alternatively, you can configure the heartbeat time (this is the amount of time a job can go without checking before it's automatically retried) for the queue with myQueue.heartbeat = <some time in seconds>

Thank you @moteus and @dlecocq.

I don't think I can call job.heartbeat() since I'm working with a single long blocking database call. The first opportunity to call job.heartbeat() would be after an hour when the query returned, and at that point I'd like to call job.complete() instead.

Setting a long heartbeat ( > than 1 hour) solved the problem of the job retrying @dlecocq.

We should be able to set 0 retries though, no?

You can run query in a separate thread or process
Also, many libraries supports async calls (e.g. some odbc drivers do)

@nvonpentz - I just looked through qless-core because I couldn't off hand remember whether retries meant attempts, or re-attempts. However, it does look like setting it to 0 should be valid, and this is just an issue with the bindings. A CR to only use the default when the retries argument is None should do the trick (and this is the canonical way to implement default arguments in python). I don't have time at the moment, but we'd certainly welcome a CR like that. In the mean time, setting heartbeat appropriately and retries to 1 should help to mitigate the problem.