Grant McNaught

I'd be happy to help with this as well.

I will assist with this.

I'm interested in this - I can assist.

So this would be a refactor to modify this library (and perhaps kue-unique as well?) to not modify the queue and job objects, but instead be separate utility objects?

I solved this on my end by looking for the existence of the data object before creating a unique job in a wrapper of kue-scheduler, it was just an unexpected...

This is due to how kue-scheduler's unique re-uses the same job for every job rather than limiting to a single instance of a job running and creating a new job...

Unique re-uses the same job in the Unique / Every scenario, so if looking at the job details it will get pushed back to inactive status on its repeating schedule:...

After digging in, the example app is not logging that the job ran because it is only triggering on job success, but unique would be firing the 'already scheduled' event...

Kue depends on keyspace notifications, does heroku redis support enabling keyspace expiration notifications? On Friday, September 2, 2016, Hao Wu [email protected] wrote: > _Hi, is anyone having the same problem?...

kue.every uses redis itself to handling the recurring schedule - in kue to re-schedule a job, you need to delete that job first before re-adding by the same name. Also...