Multiple RabbitSubscribe Decorators in the Same Provider rotates through decorated methods rather than invoking the correct method

[ianjkaplan]

The following is an issue I ran into only after much debugging in the @golevelup/nestjs-rabbitmq package.

Reproduction Register Provider with multiple RabbitSubscribe decorators that share a queue but subscribe to different topics on an exchange (i.e appointment.schedule.created and appointment.schededule.updated).

import { RabbitSubscribe } from '@golevelup/nestjs-rabbitmq';
import { Injectable } from '@nestjs/common';

@Injectable()
export class AppointmentSchedulingService {
  @RabbitSubscribe({
    exchange: 'exchange1',
    routingKey: 'appointment.schedule.created',
    queue: 'subscribe-queue',
  })
  public async createdHandler(msg: {}) {
    console.log(`Created appointment `, msg);
  }
  @RabbitSubscribe({
    exchange: 'exchange1',
    routingKey: 'appointment.schedule.updated',
    queue: 'subscribe-queue',
  })
  public async updatedHandler(msg: {}) {
    console.log(`Updated appointment `, msg);
  }
}

publish multiple appointment.schedule.created events quickly to the exchange exchange1.

expected behavior

the createdHandler will be invoked twice.

actual behavior

the createdHandler is invoked one time and the updatedHandler is invoked one time.

I would expect that I could register multiple handlers in a provider that get invoked with different routing keys. I would not expect a handler with a different routing key to get invoked.

Any help better understanding the source of this issue would be appreciated and Id be happy to help contribute a solution if one is necessary

[rafaelsanti420]

why is this closed? im experiencing this right now, this is not fixed in 3.7.0 or 4.0.0

[WonderPanda]

I agree that this is something that should be addressed but the simple fix right now is to avoid using the same queue name for multiple hanlders. It messes up the bindings and causes your NestJS callback to get registered

[tobecwb]

this problem still occurs in version 5.1.0

[rguzg]

This problem still occurs in 5.2.0. Managing queues this way is an important feature for any event driven system; this should be one of your top priorities.