Behrad Zari
Behrad Zari
Any solution?
Exposing underlying `rate-limiter-flexible` instance would be handy to build custom (nested) limiters in services/controllers
> I'd like to keep the job queue in-memory without having to make calls to redis If you don't need distribution and delayed jobs, You'd better use a control flow...
correct solution to handle stuck jobs is `ttl` feature which is added to `0.9`. When shutting down, there we can't define a clear logic for Kue to recognize `stuck` jobs...
not a bad argument since we have added workerId, I should think more about this
> it would be enough with simply flushing the whole database (or all keys with prefix) when kue.createQueue this only is feasible in dev environment, nearly in no real-world deployment...
a PR is welcome to check and handle all active jobs with the shutting down worker id
by handle I mean failing ;)
note that `watchStuckJobs` watches active jobs which are stuck caused by redis hard/connection errors guys :)
in `createClientFactory` You should return a configured client instance not the factory method `app.redisClient`