In Mule 3, when a message was filtered, the flow ended silently at that point.
The Validation module fails the flow when a condition is not met,
which makes the migrated flow handle the VALIDATION error.
The flow with the source for sending the response has to
account for the VALIDATION error, which you can do by setting a variable in
an error handler for validation errors, for example:
Mule 4 example
<flow name="flow">
...
<validation:is-true expression="#[...]"/>
...
<error-handler>
<on-error-propagate type="MULE:VALIDATION">
<set-variable variableName="filtered" value="true"/>
<on-error-propagate/>
</error-handler/>
</flow>
You can then query the set variable in the source’s error response builder to
send an appropriate response to the client. For instance, the
http:listener source might be something like this:
Mule 4 example
<flow name="flow">
<http:listener config-ref="listenerConfig">
<http:error-response statusCode="#[if (vars.filtered) 400 else 500]"
reasonPhrase="#[if (vars.filtered) 'Bad Request' else 'Internal Server Error']">
<http:body>#[error.description]</http:body>
</http:error-response>
</http:listener>
...
<validation:is-true expression="#[...]"/>
<error-handler>
<on-error-propagate type="MULE:VALIDATION">
<set-variable variableName="filtered" value="true"/>
<on-error-propagate/>
</error-handler/>
</flow>
In this case, a 400 (Bad Request) code will be returned if the event is filtered.