Always emit errors, even if they are worker errors.

[jhalickman]

This allows us to handle errors in code and pass them to a centralized error handler like sentry.

[behrad]

Why don't you bind on job 'error' events?

[jhalickman]

I wanted to bind to all worker errors at the top level, not have to do it for each instance of the job.

[behrad]

Job errors are emitted when they are marking failed and aggregating them with normal worker errors has two drawbacks:

1. Normal errors (job failures) are mixed up with Exceptional errors (non-normal worker errors)
2. Everybody should listen to kue/worker errors so that program doesn't exit when their jobs fail.

I close this.

[jhalickman]

Do you have an example of listening to kue/worker errors?

On Tue, Apr 22, 2014 at 1:33 PM, Behrad notifications@github.com wrote:

Job errors are emitted when they are marking failed and aggregating them
with normal worker errors has two drawbacks:

1. Normal errors (job failures) are mixed up with Exceptional errors
   (non-normal worker errors)
2. Everybody should listen to kue/worker errors so that program doesn't
   exit when their jobs fail.

I close this.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/314#issuecomment-41069452
.

[behrad]

kue.createQueue().on( 'error', function(){} );

[jhalickman]

Oh yeah, I am doing that, the question should have been listening to job
errors. Is this done on the worker side?

On Tue, Apr 22, 2014 at 2:23 PM, Behrad notifications@github.com wrote:

kue.createQueue().on( 'error', function(){} );

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/314#issuecomment-41075618
.

[behrad]

job.on( 'error', function(){})

You can do this on both sides, but my question is that why you would do it on the worker side?
The worker is the one who fails (emits that events) and knows about the job failures, So that would be rational to bind to failure errors on producer side. (which is also currently done by listening to failed and job failed events)
So currently I can't imagine why one should listen to job errors?

[toddbluhm]

@behrad Could this error event get some documentation on the front page...or atleast be noted that it does exist :) (Unless I am totally oblivious to API documentation somewhere else).

[behrad]

Sure @toddbluhm Dya mean #409 ?

[toddbluhm]

@behrad Thanks! Clearly I'm completely oblivious :)

[FredericLatour]

@behrad How would you listen to errors on the producer side when submitting jobs through the REST "api"?

Because of that I'm trying to get failded job at the worker side...

var jobs = kue.createQueue();
jobs.on('failed', function (id, result) {
   var res = result;
   console.log(result);
});

And unfortunately it seems like this never get called ... Obviously I must have missed something...

[behrad]

@behrad How would you listen to errors on the producer side when submitting jobs through the REST "api"?

You should poll https://github.com/LearnBoost/kue#get-jobid and checkjob.status after create job POST request returned you an id :)

And unfortunately it seems like this never get called ...

when binding to queue level events, you should prefix event name with 'job':

var jobs = kue.createQueue();
jobs.on('job failed', function (id) {
   console.log(id);
});
`