Queue management

[fedorstepanovv]

I use Nest Js. In order to work with a queue, i need to register it in a module:

    BullModule.registerQueueAsync({
      name: REFLECTION_REMINDER_QUEUE,
      useFactory: async (configService: ConfigService) => ({
        connection: {
          host: configService.getOrThrow<string>('redis.host'),
          port: +configService.getOrThrow<number>('redis.port'),
          password: configService.getOrThrow<string>('redis.password'),
        },
      }),
      imports: [ConfigModule],
      inject: [ConfigService],
    }),

It works great when you just need to use this queue in a single module. Although I have to delete all user's jobs from different queues in a seperate module. It means I need to register those queues in a seperate module which is responsible for deletion.
My concern is that if its ok to register same queues in different modules. Additionaly I try to clean up resources so I handle it in beforeApplicationShutdown like so: this.reflectionReminderQueue.close();.
Is it ok to call close for the same queue in different modules?

[manast]

The best would be if you ask this in the nest/bullmq repo, as this team is not responsible for the nest module and we are not so familiar with it.

[fedorstepanovv]

It's not only related to nest. It's about what approach is recommended to use when you need to use queues in different modules, and how to close queues when they are in different modules. Modules is not only a nest-specific topic.

[manast]

I am not sure what you mean with modules in this context. You close the queues when the process is going to be shut down like you would do with any other connection, to a database or similar. https://docs.bullmq.io/guide/going-to-production#gracefully-shut-down-workers

[fedorstepanovv]

I found the answer here. https://stackoverflow.com/questions/75205587/bullmq-add-jobs-to-queues-from-different-service-to-worker. So basically we can easily register the same queue in different places, because queue is an instance of facade class that serves as an api to add jobs to queues in Redis, not the queue itself.
So it's ok for each service to have their own instance of such facade, as the source of truth is Redis.