{"action":"created","issue":{"url":"https://api.github.com/repos/chanks/que/issues/94","labels_url":"https://api.github.com/repos/chanks/que/issues/94/labels{/name}","comments_url":"https://api.github.com/repos/chanks/que/issues/94/comments","events_url":"https://api.github.com/repos/chanks/que/issues/94/events","html_url":"https://github.com/chanks/que/issues/94","id":59842199,"number":94,"title":"Support for not retrying a failed job","user":{"login":"Sinjo","id":237226,"avatar_url":"https://avatars.githubusercontent.com/u/237226?v=3","gravatar_id":"","url":"https://api.github.com/users/Sinjo","html_url":"https://github.com/Sinjo","followers_url":"https://api.github.com/users/Sinjo/followers","following_url":"https://api.github.com/users/Sinjo/following{/other_user}","gists_url":"https://api.github.com/users/Sinjo/gists{/gist_id}","starred_url":"https://api.github.com/users/Sinjo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Sinjo/subscriptions","organizations_url":"https://api.github.com/users/Sinjo/orgs","repos_url":"https://api.github.com/users/Sinjo/repos","events_url":"https://api.github.com/users/Sinjo/events{/privacy}","received_events_url":"https://api.github.com/users/Sinjo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-03-04T18:47:56Z","updated_at":"2015-03-04T19:26:48Z","closed_at":null,"body":"Que makes the assumption that any failed job should be re-enqueued. There are failure cases where we don't want to keep retrying a job, and right now there's no way of handling them with Que.\r\n\r\nTo be specific, we only want to retry on errors we consider transient. This usually means connectivity issues, which fall into a known list of exceptions.\r\n\r\nIf, for example, there's an issue in the job logic which causes the job to fail, we'd rely on our exception tracker to inform us, and intervene manually, then re-enqueue the job.\r\n\r\nThere's a few options I've thought about to handle this:\r\n\r\n* Make the `retry_interval` proc contact our error tracker, and set the job to be retried at timestamp [infinity](http://www.postgresql.org/docs/9.1/static/datatype-datetime.html#AEN5827)\r\n* Modify Que so that it marks the job to not be retried in some way (eg setting `run_at` to `nil`)\r\n* Modify Que so that failed jobs which aren't rescheduled get moved to a different table.\r\n\r\nI'd be really interested in hearing your opinions on handling this kind of failure. I'm kind of assuming this is a situation a bunch of people run into."},"comment":{"url":"https://api.github.com/repos/chanks/que/issues/comments/77227579","html_url":"https://github.com/chanks/que/issues/94#issuecomment-77227579","issue_url":"https://api.github.com/repos/chanks/que/issues/94","id":77227579,"user":{"login":"chanks","id":300058,"avatar_url":"https://avatars.githubusercontent.com/u/300058?v=3","gravatar_id":"","url":"https://api.github.com/users/chanks","html_url":"https://github.com/chanks","followers_url":"https://api.github.com/users/chanks/followers","following_url":"https://api.github.com/users/chanks/following{/other_user}","gists_url":"https://api.github.com/users/chanks/gists{/gist_id}","starred_url":"https://api.github.com/users/chanks/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chanks/subscriptions","organizations_url":"https://api.github.com/users/chanks/orgs","repos_url":"https://api.github.com/users/chanks/repos","events_url":"https://api.github.com/users/chanks/events{/privacy}","received_events_url":"https://api.github.com/users/chanks/received_events","type":"User","site_admin":false},"created_at":"2015-03-04T19:26:48Z","updated_at":"2015-03-04T19:26:48Z","body":"Setting run_at to nil won't be a simple fix, since it's part of the primary key. Setting run_at to infinity might work without modification, but if you accumulated a bunch of them it might slow down the index scan that finds the next available job to lock (not sure about that). You could also inserting it into a separate table as you destroy it, or just set the queue name for the job to \"do_not_run\" or something like that, and just never run a worker that works on that queue. The separate table is probably the most foolproof?\r\n\r\nI don't think it's a very common situation (I think the default of retrying with an exponential backoff makes sense for the vast majority of cases), but I'm curious to hear what you decide and how it works out."}}