Closed mromanuk closed 3 years ago
I think you're referring to discrete, defined steps that can be completed, then calculated and reported as each step is completed.
Why not have your job handler be responsible for this? pg-boss is calling the function you provide, and it's difficult to train the job supervisor how to understand what "progress" means, unless you're referring only to a time interval comparison from the start date and the expiration config.
I think you're referring to discrete, defined steps that can be completed, then calculated and reported as each step is completed. Why not have your job handler be responsible for this? pg-boss is calling the function you provide, and it's difficult to train the job supervisor how to understand what "progress" means, unless you're referring only to a time interval comparison from the start date and the expiration config.
1) Yes, in my case, I'm exposing a REST API with an update endpoint, I will update the jobs after this signal from the Job Handler.
2) More generally, this could be any data about the job. I understand your point. I was referring to something like this:
queue.on('job progress', (jobId, progress) => {
console.log(`Job ${jobId} reported progress: ${progress}%`);
});
This example was extracted from this Redis Queue: https://github.com/bee-queue/bee-queue#jobreportprogressn, I think it's a nice feature.
If a job handler is calling a function in pg-boss that only emits an event, what you're mentioning is an "event emitting abstraction" and no persistence in the job table. These events would be limited to the memory space of a single instance of pg-boss. The value proposition of this is then "I would rather not create my own EventEmitter".
Is there a way to notify the progress of a long task? Something like this:
Thank you for this wonderful lib!