Vaughn Iverson

Hi, if the worker has already grabbed the job into it's internal "queue" then the answer is no, because the JobCollection will show that job as `running`, even though within...

If `jc.promote()` is the default 15s, then on average it will take 7.5s for a job whose wait time has passed to be marked as ready. Then there will perhaps...

Can you point me to a minimal reproduction of this behavior? I'd be happy to take a look if you can provide a working (simple) project that demonstrates these timings.

No problem. I probably wouldn't be able to look at it until sometime next week anyway.

Hi, yes, it should be possible to use the new npm package support to load later.js directly. I'll look into it! Thanks for reporting this.

Thanks for the research into this. Needless to say, this task hasn't bubbled up to be my highest priority, but I'll try to work this into the next update.

@mitar I concur.

Hi, thanks. Good catch. That bit of documentation dates from when Meteor used MongoDB 2.6, and from your linked article it seems like the fact that it worked at all...

A JobCollection is a `Mongo.Collection` under the hood, so you should be able to do these things directly if you look at the [data model](https://github.com/vsivsi/meteor-job-collection#job-document-data-models) and then write appropriate Mongo...

Note that in the newly released version 1.2.0 there is a new method `job.ready()` that will accomplish query 3 above more safely: ``` js // Make this job ready to...