StreamBridge removing BindingProperties leads to wrong destination in ProvisioningProvider

[esterren]

Description
Calling StreamBridge.send() sends Messages to the BindingName instead of the configured Destination, although the Desitnation Property is set.

We have a custom ProvisioningProvider and AbstractMessageChannelBinder Implementation for JDBC. Nonetheless the Method public ProducerDestination provisionProducerDestination(String name, ProducerProperties properties) in the ProvisioningPovider Implementation should be called from the AbstractMessageChannelBinder with the Destination set by the Property spring.cloud.stream.bindings.foobar1-out-0.desitination (eg. "foobar1"). But instead it is called with foobar1-out-0, the Name of the Binding.

In the same ApplicationContext we are using StreamBridge, to send Messages to these Bindings (e.g. streamBridge.send("foobar1-out-0", data);), which then should send the message to the configured Destination set by the Property spring.cloud.stream.bindings.foobar1-out-0.desitination.

Up to Version 5.0.2 (including) this did work. Since the Version 5.0.3, the StreamBridge removes BindingProperties (cp. 07eb699#diff-5e17c4149c35b951bd7e88675c6fab6589366819948092156fd0b70573f25632), which i suspect to cause the Issue.

To Reproduce
Steps to reproduce the behavior:

1. Implement a Custom ProvisioningProvider Implementation with a fixed number of Bindings (must be greater then spring.cloud.stream.dynamicDestinations, defaults to 10). For the following Example I reduced dynamicDestinations to 2 and 2x3 Bindings (Producer and Consumer).

spring:
  cloud:
    function:
      definition: >
        foobar1Consumer;foobar2Consumer;foobar3Consumer
    stream:
      dynamic-destination-cache-size: 2
      bindings:
        foobar1-out-0:
          destination: foobar1
          producer:
            required-groups:
              - foobar1Group
        foobar1Consumer-in-0:
          # same destination as foobar1-out-0
          destination: foobar1
          group: foobar1Group
        foobar2-out-0:
          destination: foobar2
          producer:
            required-groups:
              - foobar2Group
        foobar2Consumer-in-0:
          # same destination as foobar2-out-0
          destination: foobar2
          group: foobar2Group
        foobar3-out-0:
          destination: foobar3
          producer:
            required-groups:
              - foobar3Group
        foobar3Consumer-in-0:
          # same destination as foobar3-out-0
          destination: foobar3
          group: foobar3Group

2. Add the Consumer Implementations for Foobar1Consumer, Foobar2Consumer, Foobar3Consumer (with a simple Log statement)
3. Call StreamBridge.send() (eg. in a Test) and assert that the Destination matches the configured Destination Value (without the '-out-0' suffix) and the Consumers receive the Message.

Version of the framework
Working Version: up to 5.0.2 (including)
Regression in Version: 5.0.3

Expected behavior
Calling the Method StreamBridge.send() with a functional Binding Name (eg. foobar1-out-0) and a configured Destination (spring.cloud.stream.bindings.foobar1-out-0.destination), in combination with a ProvisioningProvider and AbstractMessageChannelBinder Implementation should always send the Message to the configured Destination under the Binding.
The StreamBridge Implementation should not remove BindingProperties loaded by the ApplicationContext from the YAML Configuration.

Workaround

• Setting the Property spring.cloud.stream.dynamicDestinations to a value >= the Number of Bindings under spring.cloud.stream.binding skips the removal and temporary fixes the issue. Unfortunately it comes at the price of higher Memory consumption.

[DidierLoiseau]

We are also affected by the issue, simply because we have more than 10 producers defined in one of our services. It took us quite some time to figure out that our configuration was actually removed from the list of bindings!

I must say I find it surprising that StreamBridge is modifying the internal state of BindingServiceProperties, this sounds like a code smell to me.

[olegz]

Will review the PR and merge shortly. Thank you @adityaanikam