Simple filtering of a message results in a warning being logged

[abiri-1mrobotics]

We've recently upgraded from Spring Boot 2.7.x to 3.1.x. Our existing Spring Integration flows suddenly start spamming the logs with:

xxxx-xx-xxTxx:xx:xx.xxx+xx:xx  WARN xxxxx --- [       Thread-x] o.s.integration.filter.MessageFilter     : The message [GenericMessage [...] has been rejected in filter: bean '...' for component '...'

Which is easily traced back to this snippet of code:

spring-integration/spring-integration-core/src/main/java/org/springframework/integration/filter/MessageFilter.java

Lines 180 to 195 in 261589a

	@Override
	public Object postProcess(Message<?> message, Object result) {
	if (result == null) {
	MessageChannel channelToDiscard = getDiscardChannel();
	if (channelToDiscard != null) {
	this.messagingTemplate.send(channelToDiscard, message);
	}
	if (this.throwExceptionOnRejection) {
	throw new MessageRejectedException(message, "message has been rejected in filter: " + this);
	}
	else if (channelToDiscard == null) {
	logger.warn(LogMessage.format("The message [%s] has been rejected in filter: %s", message, this));
	}
	}
	return result;
	}

Our flow is simple, it has this in the middle of it:

# SomeConfiguration.kt

@Bean
fun someFlow() =
    from(...)
    ...
    .filter(PayloadTypeSelector(...))
    .handle(...)
    .get()

This code hasn't changed and produced no warnings in Spring Boot 2.7.x.

Are we doing something wrong and/or have we missed something in the docs that says we need to do something special with filtered messages? Or is this just a bug of over-zealous logging?

[artembilan]

This is expected behavior to mitigate the situation when messages disappear unexpectedly.
See more details in the fix: #8579.

And here is some Migration Guide note: https://github.com/spring-projects/spring-integration/wiki/Spring-Integration-6.0-to-6.1-Migration-Guide#filter-warn-about-discarded-message
And docs, respectively: https://docs.spring.io/spring-integration/reference/filter.html#filter-xml

If the throwExceptionOnRejection == false and no discardChannel is provided, the message is silently dropped and an o.s.i.filter.MessageFilter instance just emits a warning log message (starting with version 6.1) about this discarded message. To drop the message with no warning in the logs, a NullChannel can be configured as the discardChannel on the filter. The goal of the framework is to not be completely silent, by default, requiring an explicit option to be set, if that is the desired behavior.

So, closing this as Works as Designed

[abiri-1mrobotics]

Thank you and sorry for missing the doc about this.

I still think it's incorrect behavior - if I filter something, then the whole point is that I want to filter it. I don't think creating a sudden WARN-level log spam is correct in this case. I'd consider making a single WARN log at startup saying "pay attention you have a filter here with no discard channel and no throw". And from there on discard silently.

[artembilan]

That is possible, but having a single warning on a start might be missed with many other logs, especially when you have a debug log level in development and switch it off for production.
As I said in that migration guide note: the framework must not be silent for lost messages.
See Javadocs of the MessageFilter: if you intend to drop them at all, then use a discardChannel.
You'll see those warnings during development and will react respectively.
Therefore technically both current solution and your suggestion are going to have same effect for development process.

[metron2]

It's not really lost though, it's intentionally filtered. You've turned filter into router.

[artembilan]

@metron2 ,

I cannot disagree with you that there is indeed some overlapping between components. In the end even router, aggregator or gateway are just variants of a service activator pattern.
I also saw some configurations where people used exactly router for true/false logic like we have with a filter.

The main point of the current behavior is to never lose the message.
This is mostly the problem with newcomers and there are many similar support requests to help people to determine why their messages are lost or gateway does not get a reply.
With such a warning by default I try to minimize my support time.
If you are good with the Framework and your goal is intentionally drop messages, then just add that extra discardChannel and move on.
It is better to have a conservative solution, then waste time on support.