[SOL-76960] Binder does not cleanup flows if flow is opened but binding creation fails

[GreenRover]

If the queue is already existing but the user is not allowed to consume the queue.

I get an error like this:

Caused by: com.solacesystems.jcsmp.JCSMPErrorResponseException: 403: Permission Not Allowed - Queue 'scst/ato-cockpit/internal/tms/ato/transactor/i-alpha/v1/trackside/event' - Topic 'internal/tms/ato/transactor/i-alpha/v1/trackside/event'
at com.solacesystems.jcsmp.protocol.impl.TcpClientChannel.createErrorResponseFromSmpFailure(TcpClientChannel.java:1033)
at com.solacesystems.jcsmp.protocol.impl.TcpClientChannel.checkSmpResponseOK(TcpClientChannel.java:999)
at com.solacesystems.jcsmp.protocol.impl.TcpClientChannel.doSmpRequest(TcpClientChannel.java:971)
at com.solacesystems.jcsmp.impl.SessionModeSupportClient.performSmpReq(SessionModeSupportClient.java:256)
... 17 common frames omitted

What so far is totally ok.

Now the binder is trying this in a endless loop without releasing the failed Flows.

What should be changed:

• The failed Flow should be closed correctly.
• In this moment the application is not healthy and should indicate it: [SOL-79060] Health indicator should capture binding health statuses #145
• If for example: "connectRetries: 2" is configured the application should give up after 2 attempts

[GreenRover]

Ping @Mrc0113

[Nephery]

The failed Flow should be closed correctly.

Yeah, this is a bug. It's failing to cleanup the flows if there's a failure during binding creation after the flow is opened, but before binding creation is complete. Like in this case, when it fails to add subscriptions after the flow is opened.

In this moment the application is not healthy and should indicate it: #145

Not entirely sure if binding creation should be captured by the health indicator (probably yes, but need to verify). If so, then this should be handled by #145 instead of this issue.

If for example: "connectRetries: 2" is configured the application should give up after 2 attempts

Binding creation retries is entirely controlled by the Spring Cloud Stream framework by spring.cloud.stream.bindingRetryInterval. If you want it to "give up", you should configure that to be 0.