Consider to deprecate and eventually remove a `replyChannel` feature on Inbound Gateways

[artembilan]

See current documentation for replyChannel feature on the Inbound Gateway: https://docs.spring.io/spring-integration/docs/6.0.1/reference/html/messaging-endpoints.html#gateway-default-reply-channel.

From all the use-case I have met so far there is no anything what we could not do without this replyChannel feature:

• We always can route back to the replyChannel header via simple bridge configuration. Or we can add an explicit router configuration for replyChannel header mapping...
• It is better to be explicit with an auditing on a specific channel before sending to the replyChannel header. It happens in this order even now anyway - first replyChannel option, then bridge to the reply channel header.

The feature is so confusing and so limited to just a PubishSubscribeChannel, that it is probably better to not have it at all. According to my experience from StackOveflow questions, people are always use this feature for Inbound Gateways (e.g. HTTP) which is not always a PubishSubscribeChannel and they are confused why their solution fails with round-robin dispatcher. Another failed use-case an attempt to short-circuit a reply from nested sub-flows. This replyChannel feature leads to an assumption that sending a message to this channel would always lead back to the Inbound Gateway, which is not always true. Really need to understand what is a replyChannel header anyway.

Without this replyChannel feature we would have only a single place of truth - a replyChannel header and all the target solutions would be more cleaner and consistent. Perhaps even newcomers to the framework will digest request-reply pattern easier without any confusions what is that replyChannel feature about.

I won't mind to reject this ticket if there is really a decent use-case for replyChannel` feature which cannot be handled by other components in the framework.

[garyrussell]

I can think of 2 use cases

• user wants to log the reply (e.g. via wire tap)
• user wants to send the reply to multiple places

Without a replyChannel on the gateway, the user would have to add a bridge-to-nowhere after the ultimate endpoint (first case) and an additional subscription (also bridge-to-nowhere) (second case).

[artembilan]

Thanks, Gary, for sharing your mind!

Those both use-case are really achievable by some other intuitive structures like you have just explained. We do use those bridges in those cases when we don't have a replyChannel anyway. According to end-user struggles it is better to give them only a single choice which would not lead to ambiguity. I feel like this feature raises concerns similar to what we have before with a log() operator in the end of flow...

Anyway: we may just reject this ticket. The goal is just remove the feature which can be replaced with other working stuff. In the end we may just adjust this replyChannel property to be only a PublishSubscribeChannel. so accident extra subscribers won't lead to the round-robin problem often raised on StackOverflow.

[artembilan]

Going to deprecate right now for 6.5, give some field battle testing before removing in the next 7.0.

[artembilan]

Turned out the reply address abstraction is so generic for Messaging per se, so, we don't have a freedom to make our own decision on the matter.

Therefore closing as Works as Designed with existing explanations in the docs how it works.