Queue API usability

[glensc]

Seems the queue api only returns boolean, no way to get any job id out of it, like for future polling of the job.

There isn't even any events on queue object (other than "error"), like could capture the job id via "job":

    worker.on("job", async (queue: string, job: Job<any> | JobEmit) => {
      await this.onJob(job);
    });

code

  const queue = new Queue({ connection: connectionDetails }, jobs);
  queue.on("error", function (error) {
    console.log('queue error:', error);
  });
  await queue.connect();
  const result = await queue.enqueue("math", "add", [1, 2]);
  console.log(result);

[glensc]

so far I've used php-resque to create jobs, and seems there the id and prefix is created by client when creating new job:

• https://github.com/resque/php-resque/blob/v1.3.6/lib/Resque/Job.php#L72-L78

and node side encode:

• https://github.com/actionhero/node-resque/blob/master/src/core/queue.ts#L46-L52
• https://github.com/actionhero/node-resque/blob/master/src/core/queue.ts#L69-L72

seems the 'queue' being encoded as value is superfluous as well in node side.

[evantahler]

There are no job-ids in Ruby's or Node-resuqe. That's a concept that the PHP fork introduced.

As we discussed in https://github.com/actionhero/node-resque/issues/334#issuecomment-638585235, I think adding Job IDs would be great addition to the package... but we don't have them yet.

[glensc]

@evantahler do you agree the queue in value is superfluous in node-resque? or it's used internally somewhere therefore needed?

[evantahler]

I don't think so... if the job is delayed, the queue param needs to be kept around to know the eventual work queue to move it into. Also, if the job fails, it will be useful to know which queue the failure was from... as perhaps you have different workers/apps working each queue.