Mule4 IBM MQ connector: In ACK mode "AUTO" - Message running in loop - infinity

Question

I have basic flow with IBM MQ Connector with all default settings (Ack Mode AUTO). If the flow throws error in between, message starts running in loop without finishing off the thread.

I expect since it is AUTO it should end the thread by seeing the error.

As far as I remember In older version 3.6 it is working perfectly in ACK mode AUTO

In Mule4 - On setting the ACK Manual or Immediate it is working fine.

I tried updating the IBM MQ Connector to v1.6.0 and also all client jar to latest '9.1.2.0'. All behaves the same.

Could anyone explain is this the default behavior of IBM Queue connector in Mule4 with ACK mode AUTO. Could anyone point out what i'm missing ?

Im using Mule version: 4.2.2

   <ibm-mq:config name="IBM_MQ_Config" doc:name="IBM MQ Config" doc:id="a217b071-0d6b-4674-8696-0a74c8e8b4ee" sendCorrelationId="ALWAYS">
<ibm-mq:connection username="admin" password="passw0rd">
    <ibm-mq:connection-mode >
        <ibm-mq:client host="${mq.inbound.host}" queueManager="${mq.inbound.queueManager}" channel="${mq.inbound.channelName}" port="${mq.inbound.port}"/>
    </ibm-mq:connection-mode>
</ibm-mq:connection>

   <flow name="NotificationFlow" doc:id="a275ef91-8608-49a5-adcc-624c2dc6aacd" >
        <ibm-mq:listener doc:name="On New Message" doc:id="5de4cf1b-bd66-4519-b170-69f2159bd8b4" config-ref="IBM_MQ_Config" destination="testQ" ackMode="AUTO"/>
        <logger level="INFO" doc:name="Logger" doc:id="9c4c241b-d564-44ff-a2a3-6433e48ddf0a" />
        <ee:transform doc:name="Transform Message" doc:id="46c10c0c-3f0a-4184-a722-7caab39ca97d" >
            <ee:message >
                <ee:set-payload ><![CDATA[%dw 2.0
import * from dw::Runtime
var result = []
output application/java
---
if(sizeOf(result) <= 0) fail('Data was empty') else result]]></ee:set-payload>
            </ee:message>
        </ee:transform>
    </flow>

Answer 1

That seems to be the expected result. When there is an error in the flow, the message is not acknowledge, so it is returned to the queue. The next read will receive the same unacknowledged message. That is called a poison message.

From the application side you could handle the error so it doesn't bubbles to the flow, with an on continue error handler. In that way the error is consumed and the message will be acknowledged when the flow completes.

If you want to manage the redelivery, you have to configure the broker (IBM MQ in this case) to handle the redelivery in a different way, like sending it to a DLQ. See the comments in this other question for more details.