Feature Request: Support for consumerTag Configuration in RabbitMQ Module

[arshadazaad3]

Description

Currently, the RabbitMQ module in @golevelup/nestjs does not support configuring the consumerTag when setting up a queue consumer. This feature would be beneficial for applications that need fine-grained control over consumer identifiers, especially in environments where multiple consumers operate on the same queue.

---

Proposed Solution

Add a consumerTag option to the queueOptions object in the RabbitMQ configuration. This tag should be passed to the underlying amqplib consumer configuration.

---

Example Usage

Here’s how the configuration could look with the new feature:

RabbitMQModule.forRootAsync(RabbitMQModule, {
  useFactory: () => ({
    uri: 'amqp://localhost:5672',
    exchanges: [{ name: 'exchange_name', type: 'topic' }],
    queues: [
      {
        name: 'queue_name',
        options: {
          consumerTag: 'custom_consumer_tag',
        },
      },
    ],
  }),
});

Benefits

• Enhanced Consumer Management: Allows applications to track and manage consumers more effectively.
• Best Practices: Supports RabbitMQ’s best practices for consumer identification.
• Ease of Use: Reduces the need for manual setup and channel management when working with consumers.

Alternatives

Developers can currently use the managedConnection to create channels manually, but this approach:

• Requires significant additional setup.

[underfisk]

@arshadazaad3 Have you explored the usage of queueOptions? We already seem to support consumerOptions which allows you to provide a consumer tag.
The way you provide consumerTag is through our decorator RabbitRPC or RabbitSubscribe

  @RabbitRPC({
    routingKey: 'rpc',
    exchange: 'exchange1',
    queue: 'rpc',
    queueOptions: {
      consumerOptions: {
        consumerTag: 'test-consumer',
      },
    },
  })
  rpc(message: object) {
    return {
      echo: message,
    };
  }

[arshadazaad3]

Thank you, @underfisk, for the clarification! I appreciate the pointer to consumerOptions within queueOptions and the example using RabbitRPC or RabbitSubscribe.

However, my request was focused on supporting consumerTag directly in the queue configuration when setting up queues via RabbitMQModule configuration (e.g., in queues array during forRootAsync or forRoot). The goal is to enable centralized configuration of consumerTag without needing to define it in decorators like RabbitRPC or RabbitSubscribe, which might not always be practical in certain dynamic or reusable module setups.

Could you confirm if this approach is feasible or if there's a specific reason it’s intentionally scoped to the decorator level?

Looking forward to your insights!

[underfisk]

@arshadazaad3 THe decorators are an easy way to inject this and I don't think we ever had the need for inject it globally and be inherited automatically which based on your use-case would reduce tons of boilerplate.

If you'd like to contribute with such change, it should be easy to plug in, you only have to make sure that if a decorator has consumerTag that it overrides the global/default otherwise we would be introducing a breaking change. Thay way, however opts in for the default/global consumerTag would know as we can make it clear as part of the JSDoc