Error info #136
Error info #136
Conversation
|
why not just pass the error object? |
|
That was was my first solution, but err.message was evaluated to 'undefined' when the error was received by the handler. My guess is that 'message' is not enumerable and ignored when the error is serialized using JSON.stringify() (events.js, line 90) |
|
yeah they're non-enumerable but it still makes more sense to pass the error and do whatever with it later |
|
Maybe I'm wrong, but that error needs to be passed from the runner to the client (i.e. where the job was created), and that system is implemented as a JSON message passed using redis. So there is no 'later', the function event.emit() will convert it to a JSON string before doing anything useful with the event. If the error (and by extension, any argument emmited with an event) has non-enumerable properties, we need to find another way to pass it to the client. |
|
Form my point of view, it is crucial that we can somehow handle errors in the failed callbacks. If a job fails, I want to be able to log it and perhaps send a notification. I could do that from inside the job processor, but I think it makes much more sense to handle this on queue or job level. |
|
This is fixed in PR #175 |
|
is fixed in #256 |
Propagate error information in 'failed' event