RabbitMQ: RabbitSubscribe using a handler name without corresponding handler config asserts randomized queues

[ckfngod]

Similar to #667

If I use RabbitSubscribe with a handler name but do not provide a corresponding handler config to RabbitMQModule then amq.gen-* queues are asserted. For example:

Given handlers:

@RabbitSubscribe({ name: 'handlerA' })
handlerA() { ... }

@RabbitSubscribe({ name: 'handlerB' })
handlerB() { ... }

@RabbitSubscribe({ name: 'handlerC' })
handlerC() { ... }

With RabbitMQModule config:

{
  handlers: {
    handlerA: [{ ... }],
    handlerB: [],
  },
  ...
}

Then a amq.gen-* queue is asserted because of the missing handlerC property in the config object. The empty array for handlerB does not cause a amq.gen-* queue to be asserted.

[underfisk]

@ckfngod What's the expected outcome? Shall we have an explicit property config to prevent such randomness? I'm not sure regarding the follow up item here but i welcome proposals

[ckfngod]

@underfisk I expected it to not assert a queue if no config is provided for a handler name regardless of how that happens. It just seems kind of strange that an explicit empty config array behaves differently than a missing property key when they both mean config is missing.

[underfisk]

@ckfngod I see what you mean. Well i haven't used in awhile and probably never ran into this issue but i'm open to allow a PR to fix or a feature flag with the proper fix to avoid any outage.
If you have the capacity to contribute such change, i would appreciate it a lot 🙏

[ckfngod]

@underfisk As I see it there's two issues here:

1. There is a difference in behaviour between empty config array and other empty config set ups (missing property, empty object in array [{}] etc.). The latter generates randomized queues whereas the former will not.
2. Not providing a queue name generates randomized queues (amq.gen-* queues)

We can fix the first issue easily so that the behaviour is aligned but I'm wondering if there's actually a valid use case for randomized queues or if we should just prevent those queues from being asserted at all.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.