When names of the Queue are unknown and provided via Async Config module

[0xTheProDev]

Is there an existing issue that is already proposing this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe it

I am facing a situation where names and respective config options of queue will not be known to me statically. Hence I would like to inject ConfigService and extract those dynamic config and pass on to BullModule.registerQueueAsync. Right now, this method expects only configs to be dynamic and names be know pre-emptively. This causing all my queues to be named default and tokenized provider with BullQueue_default. I would like to explore an option where it is possible to have Queue names dynamic as well.

Describe the solution you'd like

I am posting a code snippet to explain my expected API:

config.service.ts:

@Injectable()
export class ConfigService {
  getQueueOptions() {
    // load config files or search envs during runtime and find these values.
    return {
      name: 'TestQueue',
      defaultJobOptions: {
        priority: 1,
      },
    };
  }

app.module.ts:

@Module({
  imports: [
    ConfigModule.forRoot(), // assume it is global.
    BullModule.forRootAsync({
      inject: [ConfigService],
      useClass: SharedQueueConfig, // this works fine.
    }),
    BullModule.registerQueueAsync({
      inject: [ConfigService],
      useFactory: (config: ConfigService) => config.getQueueOptions(), // this doesn't work.
    }),
  ],
})
export class AppModule { }

Teachability, documentation, adoption, migration strategy

No response

What is the motivation / use case for changing the behavior?

I would, for my use case, like to keep all the Queue Definitions and the default Job Options central to a config object and load it in config module during runtime. I would like to have global scope for all the queues such that no two queues can have same name, and can produce/consume jobs from any module in my application.

[micalevisk]

not sure if I follow. Is that ConfigService from @nestjs/config or something you've made?

[0xTheProDev]

@micalevisk Assume it is from @nestjs/config. In broader scope of the issue, it does not really matter where the config is coming from, but the fact that it is coming from other module.

[micalevisk]

Alright. It's just a globally available provider. Got you

[kamilmysliwiec]

Thanks for your suggestion!

This has been discussed in the past and we decided to not implement it in the foreseeable future.

If you think your request could live outside Nest's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.