Manuel Astudillo

We will need to use the jobId option for this, since that is the proven mechanism we have today to avoid duplicated jobs. In your case it should work since...

@veedeo this is feasible but only if the overwrite is done before the job has actually started to be processed, it should be as easy as having an extra option...

The way to move forward with an issue like this is by providing an example code that clearly shows the memory is actually rising and that somebody else can also...

Thanks for the report. Yes, this sounds like an oversight from my part, a job progress should only be possible to perform while a job is in active state and...

For job.update I do not think it is necessary to check for a lock, since usually this method is used outside of the processor, on the other hand it could...

I answered to this issue here: https://github.com/taskforcesh/bullmq/issues/856

actually I think it would be as easy as only swalling "Connection is closed" error, since this error happens when we force to close the connection with redis, should be...

if you provide a PR I will merge it quickly and make a release. It is as mentioned as simple as only swalling the error in case of connection is...

The thing is that the current PR does not do anything valuable. I am not sure which solution is the best here, basically I think we need to just delay...

@tnolet not sure if you are aware but this issue has been addressed some time ago https://github.com/OptimalBits/bull/pull/1974 Let me know if that is not the case.