[Bug]: changePriority Confusing behavior when updating priorities
Opened this issue · 5 comments
Version
latest
Platform
NodeJS
What happened?
const job = await generateQueue.getJob('1');
console.log(job.opts.priority); // 2097052
//jobId 1 before update job.opts.priority is 2097052
await job.changePriority({
priority: 2097045
});
//jobId 1 after update job.opts.priority is still 2097052
const _job = await generateQueue.getJob(job.id);
console.log(_job.opts.priority); //still 2097052
When I look up the raw Redis key, I got this
bull:generate:1 => {b'timestamp': b'1728168935500', b'priority': b'2097045', b'delay': b'0', b'name': b'1', b'opts': b'{"removeOnComplete":1000,"removeOnFail":5000,"priority":2097052,"delay":0,"attempts":0}', b'data': b'{"id":"1"}'}
.
The priority
has been updated, but opts.priority
has not. It looks like the priority update is working, but the results are confusing.I don't know if this is expected behavior and will the priority change really make that task be picked earlier?
How to reproduce.
No response
Relevant log output
No response
Code of Conduct
- I agree to follow this project's Code of Conduct
hi @LianZiZhou opts is expected to be changed. The only change that matters is priority attribute
hi @LianZiZhou opts is expected to be changed. The only change that matters is priority attribute
Thanks for your reply. What is very confusing to me is that in my test opts cannot be changed anyway.
Redis 7.2.4 / NodeJS v20.9.0 / bullmq (4.12.7/5.16.0)
When should opts be updated?
https://github.com/taskforcesh/bullmq/blob/master/src/commands/changePriority-7.lua#L54
Will this script update the parameters in opts?
@roggervalf it is interesting that there is no priority field for the Job class either, so it is actually not possible to know the priority of a job after it has been changed with changePriority, even though we know it works based on the tests.
@roggervalf it is interesting that there is no priority field for the Job class either, so it is actually not possible to know the priority of a job after it has been changed with changePriority, even though we know it works based on the tests.
Maybe need priority field for the Job class? Read priority directly instead of opts.priority
.
If I didn't understand this problem, I might only be able to read the raw value from Redis to reliably get the current priority of the Job.
oh yeah I was thinking that we were handling priority as delay attribute, but this is not the case. I'll work on adding this field in Job class