Enhancement: Adding Failed Body for extended error objects

[zachlevy]

I'm sure a lot of projects, including a couple of mine, use extended Error objects

A simple example would be

const err = new Error('An error message');
err.code = 'SOME_APP_ERROR_CODE';
> JSON.stringify(err);
'{"code":"SOME_APP_ERROR_CODE"}'

https://github.com/goldbergyoni/nodebestpractices/blob/master/sections/errorhandling/useonlythebuiltinerror.md#use-only-the-built-in-error-object

In bull, when saving a failed job processing attempt, it stores the stack trace and the error message, it would be great to store any extended error attributes also.

params.failedReason = err.message;
params.failedBody = JSON.stringify(err);

[alolis]

@zachlevy, this is definitely something useful. In the meanwhile, you can check this out as an alternative approach. Works very nicely for me.

@manast, I have another proposal for this. Instead of introducing a new property, you could also do the following here:

Job.prototype.moveToFailed = async function(err, ignoreLock) {
  err = err || { message: 'Unknown reason' };

  this.failedReason = (err instanceof Error) && _.isFunction(err.toJSON) ? err.toJSON() : err.message;

  // ... code
}

So, if someone wants to use a custom error object, all they have to do is implement toJSON in their extended Error object. Needs some further thinking though; what if someone wants the message even if Error implements toJSON ? or is it just fine?

Using the property failedReason as both JSON and string is not something new with bull; progress does the same so it might be a good idea in order to have a unified behavior instead of introducing another property to the Job object.