Vaughn Iverson

Hi, I think you misunderstand. You can use `async.series` to manage the callback pyramid when creating and saving your jobs. Even creating the dependent jobs is a series of async...

I really can't say without seeing your actual code. It's all guesswork without the running code in front of me. The return value to the callback is the `_id` of...

@serkandurusoy Yup, that's a bug in the example code. Should be: ```js // Create a job: var sendJob = new Job(myJobs, 'sendEmail', { address: '[email protected]', subject: 'Critical rainbow hair shortage',...

Save terminates the chain because once you have saved the job, you need to pause it first in order to modify and save it again. That was intentional.

And also, `job.save()` is an async operation, so it can't be chained in a non-fiber environment.

Hi, thanks for the question. job-collection is not a "real-time" system, in that it only makes a "best effort" to run/repeat/retry jobs when you ask them to. In your case...

I wouldn't have the worker fail. I'd simply sleep it (with `setTimeout()`) for some amount of time (500ms?) and have it try again when it wakes up.

Hi, running jobs cannot be paused in the way you are assuming. If you look at the [definition](https://github.com/vsivsi/meteor-job-collection#jcjobstatuspausable---anywhere) of `jc.jobStatusPausable` you will find: ``` js jc.jobStatusPausable = [ 'ready', 'waiting'...

I want to add that you could certainly define workloads that can be "partially completed" by using persistent state pointed to by the job `data`. Cancelling such a worker would...

What precisely do you mean by "restart"? Like any functionality built on top of a database, a jobCollection will generate errors when the database isn't accessible. Assuming Meteor itself does...