Oversight on task_progress event?

[sbasher314]

Hello, I am recently working on a project using better-queue. I presume that the progressTask function should be able to work as a partial (say, inserted 10/100 records) and should be able to display that a task / ticket is 10% complete. However, utilizing either progressTask or progressBatch causes the ticket to stop being tracked / updated - I believe the below code is why:

worker.on('task_progress', function (id, progress) {
    var taskId = taskIds[id];
    if (tickets[taskId]) {
      tickets[taskId].progress(progress);
      delete tickets[taskId];
    }
    self.emit('task_progress', taskId, progress);
  })

It looks like this is almost identical behavior to the worker.on('task_finish) listener, and may have erroneously been copied over:

worker.on('task_finish', function (id, result) {
    var taskId = taskIds[id];
    var stats = updateStatsForEndedTask(taskId);
    if (tickets[taskId]) {
      tickets[taskId].finish(result);
      delete tickets[taskId];
    }
    self.emit('task_finish', taskId, result, stats);
  })

For my purposes, simply commenting out / removing the line delete tickets[taskId] in the task_progress listener above resolves this issue, and I do not see it breaking expected behavior. I just want to make sure that this is not the intended behavior, or if this conflicts with anything in any way.

[leanderlee]

I’m not sure I understand your issue completely. Can you provide some example code to illustrate the problem?

…

On Wed, Sep 7, 2022 at 10:44 AM Steven Basher ***@***.***> wrote: Hello, I am recently working on a project using better-queue. I presume that the progressTask function should be able to work as a partial (say, inserted 10/100 records) and should be able to display that a task / ticket is 10% complete. However, utilizing either progressTask or progressBatch causes the ticket to stop being tracked / updated - I believe the below code is why: worker.on('task_progress', function (id, progress) { var taskId = taskIds[id]; if (tickets[taskId]) { tickets[taskId].progress(progress); delete tickets[taskId]; } self.emit('task_progress', taskId, progress); }) It looks like this is almost identical behavior to the worker.on('task_finish) listener, and may have erroneously been copied over: worker.on('task_finish', function (id, result) { var taskId = taskIds[id]; var stats = updateStatsForEndedTask(taskId); if (tickets[taskId]) { tickets[taskId].finish(result); delete tickets[taskId]; } self.emit('task_finish', taskId, result, stats); }) For my purposes, simply commenting out / removing the line delete tickets[taskId] in the task_progress listener above resolves this issue, and I do not see it breaking expected behavior. I just want to make sure that this is not the intended behavior, or if this conflicts with anything in any way. — Reply to this email directly, view it on GitHub <#87>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACMO2WE6J2NAGP6YSIFMVDV5DH6TANCNFSM6AAAAAAQG7PQK4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sbasher314]

Sure -

Lets say I have some number of operations to complete for a single task. We will use a for loop for simplicity -

const iterationCount = 100
for (let i = 1;  i <= iterationCount; i++) {
  this.progressTask(0, i, iterationCount, 'iterations')
}

I would like to be able to know how many operations occurred in this task up to some point.

After the first progressTask usage, the ticket is deleted from the worker / queue and does not receive further updates, such as the final result, status, or eta. The other events still mostly appear to work as expected.

The context is that I am using a sort of ticket tracking system to store progress, results, status, etc, and refer to the original ticket object.

I could potentially rewrite the system to use a bunch of listeners instead, but I'm still not sure how deleting the current ticket on a progress event is beneficial (what if the ticket fails after progress has occured?)

[leanderlee]

Hmm, yeah, I think you're right. This does seem like an oversight... Weird that no one caught this! Fix incoming

[leanderlee]

Fix pushed to 3.8.11

[sbasher314]

Awesome, thanks!