{"action":"closed","issue":{"url":"https://api.github.com/repos/timgit/pg-boss/issues/3","repository_url":"https://api.github.com/repos/timgit/pg-boss","labels_url":"https://api.github.com/repos/timgit/pg-boss/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/timgit/pg-boss/issues/3/comments","events_url":"https://api.github.com/repos/timgit/pg-boss/issues/3/events","html_url":"https://github.com/timgit/pg-boss/issues/3","id":167104764,"number":3,"title":"Would like to see a big picture overview","user":{"login":"jtlapp","id":138133,"avatar_url":"https://avatars.githubusercontent.com/u/138133?v=3","gravatar_id":"","url":"https://api.github.com/users/jtlapp","html_url":"https://github.com/jtlapp","followers_url":"https://api.github.com/users/jtlapp/followers","following_url":"https://api.github.com/users/jtlapp/following{/other_user}","gists_url":"https://api.github.com/users/jtlapp/gists{/gist_id}","starred_url":"https://api.github.com/users/jtlapp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jtlapp/subscriptions","organizations_url":"https://api.github.com/users/jtlapp/orgs","repos_url":"https://api.github.com/users/jtlapp/repos","events_url":"https://api.github.com/users/jtlapp/events{/privacy}","received_events_url":"https://api.github.com/users/jtlapp/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":13,"created_at":"2016-07-22T18:29:51Z","updated_at":"2016-09-18T00:35:55Z","closed_at":"2016-09-18T00:35:55Z","body":"I've never used a transactional queue before and find myself having to infer the overall design from the API and configuration docs. I'm not sure I'm getting it right. It would be nice for the docs to include a big picture overview.\r\n\r\nIt seems that you implement a single queue of virtual queues, each virtual queue corresponding to a job name. Each job consumer subscribes to a virtual queue by job name.\r\n\r\nWhen a job consumer receives a job, it processes the job and then calls a queue-provided callback to report job completion. The job may then be archived, meaning that it is removed from the virtual job queues and yet somehow also still available.\r\n\r\nQuestions:\r\n\r\n(1) How does a job consumer report failure, such as to requeue the job for another attempt later?\r\n(2) Can failed jobs be requeued with a delay not indicated when the job was originally queued? (I'll be downloading web pages, may want to wait before retrying.)\r\n(3) Can I process jobs statefully? In my case, I need to queue a job to load an image from the web. Once successfully loaded, I then need to queue the job for conversion to a thumbnail. Can I just change the job name to put the job in a new queue? Or is this a dequeuing of the first job and a queuing of a second job in a new virtual queue?\r\n(4) I'm not seeing an option not to archive jobs. Is archival somehow necessary? My project doesn't seem to need archival, because each job results in a downstream database record.\r\n(5) How do I access archived jobs? How do I get rid of old ones? Would I need to code to your schema, or do you somehow provide access?\r\n\r\nIt would help to not only have answers to these particular questions, but also clarification of the big picture that such questions suggest I'm missing. Thank you! Looking forward to using your module...\r\n"}}
{"actor":{"display_login":"timgit"}}