What is the correct order to close the queue and workers?

[mattweberio]

Hi All, We create a BullMQ Queue in one app. Another app polls Redis for new queues and then spawns a BullMQ worker to manage each queue. The first app closes the queue when done (I've tried deleting, obliterating, etc. - everything in the docs). However, something continuously regenerates the Queue in Redis and keeps the connections alive. I suspect the BullMQ workers are not automatically closed when the queue is destroyed. What is the correct method or sequence of events to tear down the Queue and Workers so all of the connections close and there are no remains in the database? Which end of the queue is in charge of tearing things down?

[manast]

Which specific keys are you finding in the Redis that belongs to a queue after calling Obliterate?

[mattweberio]

Thanks for the reply. After trying to delete or obliterate it, I typically find a hash named ‘meta’ and a key with the queue name containing ‘meta, events, and id’. We are trying to delete the queue from the app that created the queue. In the app that contains the workers consuming queues we just provide the work the queue name and assume it will stop once the queue is deleted. Our theory is that the worker keeps the queue alive and that's why we have these remains and connections refuse to close.

[mattweberio]

What I have found is that you must do the following:

await instance.obliterate({ force: true })
await instance.close()

If you only obliterate the queue, then the connections remain open. If you only close the connections, then the queue has remains. However, this combination appears to work when wrapped in a setTimeout of a few seconds to allow the workers to empty any remaining items. I would love to hear feedback if this is expected. We are creating queues on the fly to manage sessions so it's critical to close all the connections and clean up the cache. I imagine this isn't common because most users are creating a single queue to manage some fixed jobs.

[manast]

It is unusual to create queues dynamically, it is more common to use groups in such cases. In any case I think the issue here is that you may still have workers running after you obliterate the queue. If you close all the workers and then use a queue instance you obliterate the queue and then close this queue instance, there should not be any remains left.