waitUntilFinished hang if removeOnComplete is set without TTL

[Embraser01]

When using the removeOnComplete option on a job, calling the waitUntilFinished will have an undefined behavior (unless ttl has been set).

If it's called before the job is cleared from the queue, it will work as intended but if the job is already removed, it will just hang indefinitely.

I think the waitUntilFinished function should warn the user if removeOn... is set as it may never resolve.

[manast]

ok, seems like a bug to me. Would you mind to provide a small snippet that reproduces the issue that we can use as a test case?

[Embraser01]

Here is a reproduction repo I made to check: https://github.com/Embraser01/bullmq-issue-85

It gives the percentage of jobs that hit the TTL with and without removeOnCompleted (I got 4% of failed jobs with it enabled).

[antoniusostermann]

Just found this - @Embraser01 did you find any way to work around this? If you set removeOnComplete to false, how do you avoid exceeding your redis' memory?

job.waitUntilFinished() is super helpful in some cases imho, but this really seems like an issue for me.

[Embraser01]

Just found this - @Embraser01 did you find any way to work around this? If you set removeOnComplete to false, how do you avoid exceeding your redis' memory?

job.waitUntilFinished() is super helpful in some cases imho, but this really seems like an issue for me.

I added a recurrent job that just clean jobs that have completed from more than X seconds (like 15/30s)

[github-actions]

🎉 This issue has been resolved in version 1.46.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀