Created by: codazzo
It lets the user specify a timeout in ms, after which the job should be failed. Example:
queue.add({some: 'data'}, {
timeout: 100 //if the job takes longer than 100ms, it is failed
});
The semantics are as such: if for any reason the job takes too long (e.g. unresponsive API), it is forced into the failed
set and the queue will process the next job. This should be an anomalous case and more of a safeguard to keep the queue from getting stuck. Users of the queue should know to handle the resulting 'failed'
event - as any event listeners and timeouts set by the job cannot be removed and may eventually be called.
Example
function handler(job, done){
setTimeout(function(){
bus.emit('ready');
}, 150);
}
In this case, once the job is failed after 100ms, users of the queue may want to remove any listener to a ready
event or otherwise the application may end up in an inconsistent state. Exactly what needs to be done would depend on the mechanics of the job and possibly on the progress reported.
This may be preferable over the queue being stuck.
This PR also contains an upgrade to mocha, which after version 1.18 supports promises. This is preferable over async (function(done)
) tests because if an assertion in the test fails, the promise is rejected with the error thrown by the assertion and mocha displays the rejection value as the reason for the failed test. With async tests, the test simply times out because done()
is never reached and one cannot see why in the console.
Any thoughts on this @manast? Cheers