Delayed job "Will run at" wrong source value

[chriscarpenter12]

When a delayed job is added it displays a "Will run at" in the UI, but if the job uses changeDelay that value is never reflected in the UI leading to confusion as the job properties look correct.

I'm not completely sure, but I think here is where it's reading from job.opts, but instead should just use the delay property on the job itself.

Comparing two job properties that have/have not been updated.

Unchanged:

{
  ...
  opts: {
    attempts: 0,
    delay: 2429862,
    removeOnComplete: true,
    jobId: undefined,
    backoff: undefined
  },
  id: '20',
  progress: 0,
  returnvalue: null,
  stacktrace: null,
  attemptsMade: 0,
  delay: 2429862,
}

Job called with changeDelay

{
  ...
  opts: {
    attempts: 0,
    delay: 2519881,
    removeOnComplete: true,
    backoff: undefined
  },
  id: '19',
  progress: 0,
  returnvalue: null,
  stacktrace: [],
  attemptsMade: 0,
  delay: 3299877,
  repeatJobKey: undefined,
  timestamp: 1678119480121,
  parentKey: undefined,
  parent: undefined,
}

[felixmosh]

Hi @chriscarpenter12 thank you for reporting this issue, I'm not using changeDelay so I'm not familiar with it :]
Let me check that.

[hyperair]

Related issue in bullmq: taskforcesh/bullmq#1728

There isn't a good way to solve this:

• job.timestamp + job.opts.delay doesn't take into account a changed delay (via job.changeDelay or job.moveToDelayed`
• job.timestamp + job.delay yields an incorrect value, because:
  • job.delay is updated by job.changeDelay and job.moveToDelayed`; but
  • job.timestamp is job creation time and not updated by either of those calls
  • job's "will run at" time should be lastUpdated + job.delay, but we don't have lastUpdated

Internally, the "will run at" time can be obtained from the job's score in the delayed zset in redis, but there isn't a public API to get that

[felixmosh]

Released in v4.12.2

[felixmosh]

usage of changeDelay, well, changes the job's delay attribute, for some reason we used the option value instead... :]

[hyperair]

@felixmosh You'll still get wrong values, just in differently now:

If a job.changeDelay() happens with a small value a long time after the job was processed:

startTS = Date.now();
job = await queue.add(..., { delay: 16 * 60 * 1000 );

// ...after 15 minutes
await job.changeDelay(60 * 1000);

job = await queue.getJob(job.id);
job.timestamp + job.delay == startTs + 60 * 1000;  // this is wrong, it should be startTS + 16 minutes

[felixmosh]

@hyperair you are right, but seems that it should be solved on the BullMQ side, not on this board.
When it will be solved by your issue, it will be reflected on the board, currently the board reflects the common use properly.

[wenq1]

see my comment in the bullmq issue