bullmq: Throw custom error class is not propagated properly to the Queue

Hi, my worker throws a custom error class, I do see the error with the relevant class name & stack trace in the Bull-Dashboard.

But when the failed event triggered on the queue process I get only the errors message field. https://github.com/taskforcesh/bullmq/blob/master/src/classes/job.ts#L375

class CustomError extends Error {
  public code: any;
  public details: string[];

  constructor(code, message, details) {
    super(message);

    Error.captureStackTrace(this, this.constructor);

    this.name = this.constructor.name;
    this.message = message;

    this.code = code;
    this.details = details;
  }
}

// worker - a separate process
const worker = new Worker(
  'queueName',
  async (job) => throw new CustomError(4004, 'Message not found', 'more details')
);

// queue - main process
queue = new Queue('queueName');
const job = await queue.add('test', { foo: 'bar' });
try {
  const result = await job.waitUntilFinished(queueEvents);
} catch (error) {
  // error.message will contain "Message not found"
  // here the error doesn't have any fields of the custom error event.  (such as name, code)
}

In bull-dashboard I do see the original error object, that means that the info exists in redis. image

I hope that the issue is clear, if not, I’m available for more details.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 24 (8 by maintainers)

Most upvoted comments

I will have to think more about it…

If you throw an error with additional fields, you won’t be able to get them (show them).

You must throw an Error, not an arbitrary object.

@mattwynne I am not super positive about this idea but I may change my opinion in the future.

It could be possible to use something like https://github.com/efossas/Javascript-Serializer within Bull to serialize the error (instead of just capturing the message and stack properties) on the Job.

Perhaps we could do this in a third property on Job so other things (like the UI) that already read the message and stack could continue to rely on them?