How does NestJS handle bindings in RabbitMQ Server?

[obsidian wraith]

I've read the source code for the rmq server and it looks like nest doesnt bind the queue to any key if the key is not specified in topic mode
it only binds in case wildcards is set to true, am I missing something? or are you supposed to handle it manually
server code:
https://github.com/nestjs/nest/blob/master/packages/microservices/server/server-rmq.ts

[twilit lodge]

Ah yeah, that's exactly how it works.
By default, in topic mode, Nest only binds queues when you either specify a routing key explicitly or use wildcards(#/*)
If you don't do either, nest leaves it unbound, you're expected to handle the binding manually if you need a default route.
It's a bit unintuitive, I agree.
Honestly, for topic exchanges I usually always set and explicit routing key or a #wildcard so the queue actually receives messages.

[obsidian wraith]

but so Like if you have wildcards as true its going to bind each key by iterating over the consumers?
so why not do it for all the decorated consumers in general or at least have an option to do so

[twilit lodge]

Yeah, basically yes. with wildcards:true Nest iterates over the consumers and binds using their patterns.
Why not do it for all decorated consumers by default? Mostly design choice+backward compatibility. Nest tries to stay explicit here and avoids “magic” bindings that could accidentally subscribe you to more topics than intended.
I agree though, an opt-in flag like autoBindPatterns:true would make sense. if you want that behavior, you kinda have to handle the binding yourself or always use #/explicit keys rn.

[obsidian wraith]

I've tried and it looks like you can just use wildcards: true and it'll do that for you even for patterns with no wildcards i guess that's our "opt in flag"
I'm not a fan of the naming, it does something different than what it implies, any future internal change can break your project if you rely on this implicit functionality so maybe we'll just do it ourselves.