Preserve Error object properties when job fails

[perrin4869]

As it stands right now, when a job fails, the only part of the error that is preserved is the message.

I think that the error should be serialized in a manner similar to the job result. If the error is a json object, then it is passed to job.on('failed', err => { ... }) as is. If the error is an Error object, then it gets serialized. I propose that for err instanceof Error, the serialization would be err => ({ name: err.name, message: err.message })

I can try to put together a pull request to get this done too.

[LewisJEllis]

I recall giving this some consideration and leaving it as a "that can probably get tricky if I go further, this'll do." While more faithful preservation can certainly be useful, if we preserve more about the error, we have to ask "well, what exact use cases do we try to support and how much do we try to preserve in this aspect or that aspect?"

Do we try to serialize whether an Error was a ReferenceError or a TypeError? Is that what you mean by err.name? Do we try to serialize all properties of the Error, or just a few specific ones? If we do share types of Errors, there's no guarantee that the same class name will mean the same thing in different contexts, so does it even make sense to try? Or do we just need a warning label about context sensitivity?

Partially motivated by wanting to dodge the above slew of questions, I decided originally that since the message field is the star of the show, it would be sufficient. I'm open to changing that, though, if we can delineate exactly what we want to support and how we'll do that.

[perrin4869]

Well, the idea is to do it in a non-opinionated way. There are two cases:

1. Like with the result, we allow a json serializable object to be passed
2. If an instance of Error is passed, then by default we setialize it into an object of name, message and stack, and we provide an optional serializeError and deserializeError that takes an Error instance and serialize into a json object, that way everyone is happy

[perrin4869]

ok I'm back home with keyboard, I can be a bit more specific. The serializeError and deserializeError would be options as in the sample below, with the values passed as the default:

var queue = new Queue('foo', {
    ...
    serializeError: (err => ({
        name: err.name,
        message: err.message,
        stack: err.stack
    })),
    deserializeError: null, // Nothing by default, although something could be worked out but not critical
    ...
});

Then, when you are done processing the job:

process(job, (err, res) => {
   ...
   err = (err instanceof Error) ? opts.serializeError(err) : err;
   err = JSON.stringify(err);
   ....
});

And when invoking the callback you would do:

job.emit('failed', (opts.deserializeError) ? opts.deserializeError(err) : err))

Hope I made things a bit clearer ^^;;
I will try to put together a pull request if I have some time!

[skeggse]

Merging with #146.

We can add support for a toJSON method on error objects. Would that work for you? That'd provide a lot of control over how error objects get serialized. Alternately, we could add support for an Error formatted/dehydrator in the Queue settings. What do you think?

[cjroebuck]

Is there no way to easily retrieve error details then, without having to serialize via the error.message

[mindnektar]

Is there any progress on this? I really like @perrin4869's solution from #41 but it seems not to have been approved. This issue is causing me a fair bit of trouble right now.