Currently, the unique functionality is only useful for recurring jobs, since the jobDataKey is not mapped to the job's definition in Redis if the job is non-recurring (ONCE).
The use case for this? Well, if we want to have some sort of management upon the jobs, such as updating some property in their definitions or even canceling them, it is not possible to do it in a "symmetrical" way - the job with its incremental ID is only set by kue on Redis once the job got processed for the first time, so we cannot use this ID if we want to cancel a scheduled job which has never been executed before. On the other hand, the jobDataKey, which is built using this.options.prefix and the unique property is not being set on Redis in case the job is non-recurring
So, mapping the job definition with jobDataKey in both ONCE and RECCUR-type jobs seems an appropriate way of doing this to me.
In this case, we could always access a job and even cancel it by using queue._readJobData(key) and then job.remove().
Currently, the
unique
functionality is only useful for recurring jobs, since thejobDataKey
is not mapped to the job's definition in Redis if the job is non-recurring (ONCE
). The use case for this? Well, if we want to have some sort of management upon the jobs, such as updating some property in their definitions or even canceling them, it is not possible to do it in a "symmetrical" way - the job with its incremental ID is only set bykue
on Redis once the job got processed for the first time, so we cannot use this ID if we want to cancel a scheduled job which has never been executed before. On the other hand, thejobDataKey
, which is built usingthis.options.prefix
and theunique
property is not being set on Redis in case the job is non-recurring So, mapping the job definition withjobDataKey
in bothONCE
andRECCUR
-type jobs seems an appropriate way of doing this to me.In this case, we could always access a job and even cancel it by using
queue._readJobData(key)
and thenjob.remove()
.