Hey @samuel,
If I understand you correctly, what you are seeing is what I would expect. That said, I agree it may not be ideal for your use case of having 2 apps that are the primary consumer on one queue and the backup on another. To explain what’s happening: the Spring Cloud Stream binder leverages the functionality provided by the Solace Exclusive queue to achieve this “Primary”, “Secondary”, “Tertiary” pattern. Because of this the first Session/Flow to bind to each queue will be the active consumer and receive all messages delivered to that queue. In your case, since both of your apps are listening to both queues the first one that starts up will receive all messages from each queue and neither instance knows if/how many other instances are bound to the same queue. Only the broker has that logic.
I’ll have to think and get back to you if there is another option, but you may have to have a separate instance that serves as the backup. A few other options that come to mind is expiring messages to a DMQ as a work around but that sounds nasty or requesting that the Solace binder be enhanced to add functionality to start/stop individual bindings as defined here
Side note - does that configuration of destination: queue0,queue1 actually work for you? I haven’t tried to list multiple destinations on a single function.
Not ideal news, but hopefully that helps and prevents you from wasting time figuring out why something is working how it is actually supposed to work ?