What's the purpose of automatically added bridge component after router?

pnescior :

After visualizing my flow (using this great project, btw.), I've noticed that there are bridge components (together with DirectChannels) inserted right after my router:

My DSL configuration:

.route(Message.class, messageTypeHeader(), mapping -> mapping
    .id("filteringRouterEndpoint")
    .resolutionRequired(false)
    .defaultSubFlowMapping(rejectedByFiltersFlow)
    .subFlowMapping(MessageType.TYPE_1, s -> s
            .channel("type1MappingChannel")
            .filter(type1MappingFilter)
            .channel(ACCEPTED_BY_FILTERS_CHANNEL_NAME))
    .subFlowMapping(MessageType.TYPE_2, s -> s
            .channel("type2MappingChannel")
            .filter(type2MappingFilter)
            .channel(ACCEPTED_BY_FILTERS_CHANNEL_NAME))
    .subFlowMapping(MessageType.TYPE_3, s -> s
            .channel("type3MappingChannel")
            .filter(type3MappingFilter)
            .channel(ACCEPTED_BY_FILTERS_CHANNEL_NAME)))

(some names are different than on the flow, just to simplify)

I've noticed, that if I don't specify the channels explicitly on the beginning of the mapping subflows (i.e. typeXMappingChannels), then the bridges aren't created:

but I want to specify channels by myself, just to know their exact name, or to have other than DirectChannel implementation for example.

What is the reason for that? Or maybe I made something wrong in my configuration?

Gary Russell :

It's an artifact of how the flow is constructed.

When we call .subflowMapping() we start to build a flow that begins with a channel. Since we haven't encountered the first element of the flow yet .channel() in your case, we build a default input channel.

Then, when we encounter the .channel() we see the previous component is a channel, so we bridge it.

We could possibly optimize it out for this specific case; I'll take a look, but it will likely be a 5.2 change if we do it.

GH-2890