Understanding and Resolving Anypoint MQ Error "LockId provided is expired"

SYMPTOM

You are processing messages from an Anypoint MQ queue, but your Mule application fails with an ACK or NACK requests. This issue can be observed when the MQ flow is configurd with maxConcurrency (i.e maxConcurrency=1) limiting the cucurrent events from the flow level.

This situation commonly arises in the following scenarios:

• FIFO queues configured with maxConcurrency=1, and the extended processing time for messages (NOTE. With FIFO, if message ordering is crucial, maxConcurrency=1 is required)
• Standard queues (with or without maxConcurrency enabled) where individual message processing takes longer than the default lock duration.

The error log contains a 400 Bad Request message with the following details:

com.mulesoft.mq.restclient.exception.RestException: An error occurred while executing the operation: ACK ONE MESSAGE. Cause: 400 - Bad Request ({
  "status" : "failure",
  "statusMessage" : "LockId: AQEBpeUWnHhPYVU....Im8Q20oe0J provided is expired"
}).

CAUSE

This error occurs when the lockID TTL is expired. The default Acknowledgement timeout for an Anyoint MQ subscriber is 2 mintues if not explicitly configured. 

Detailed Message Flow Analysis (FIFO with maxConcurrency and long processing duration)

SOLUTION

1.Increase TTL for the acknowledgementTimeout in the subscriber configuration. The default TTL is two minutes.

For example:

	<anypoint-mq:subscriber doc:name="Subscriber" doc:id="5100fdd2-752b-49bf-9d12-53409da59b4e" destination="testing-fifo" acknowledgementMode="MANUAL" config-ref="Anypoint_MQ_Config" acknowledgementTimeout="5" acknowledgementTimeoutUnit="MINUTES">
			<anypoint-mq:subscriber-type >
				<anypoint-mq:polling>
					<scheduling-strategy >
						<fixed-frequency />
					</scheduling-strategy>
				</anypoint-mq:polling>
			</anypoint-mq:subscriber-type>
		</anypoint-mq:subscriber>

2. Reduce the polling size. 

If the average or worst-case message processing time is relatively long, maintaining a polling size of 10 increases the likelihood of encountering lock ID expiration errors. This is because, with maxConcurrency=1, all 10 messages are fetched at once but processed sequentially — one message at a time due to the limitation set on the flow level.

By the time the first few messages are fully processed and an ACK is sent, the lock TTL for later messages may have already expired. This leads to the HTTP 400 – “LockId provided is expired” error when the ACK is attempted.

To prevent this, consider reducing the polling size (i.e 1 or 2) so that fewer messages are fetched per poll, aligning the total processing time with the lock duration.

Note:
This behavior is not a bug in the Anypoint MQ connector.
Messages are processed sequentially because maxConcurrency=1 is explicitly configured at the flow level, which limits parallel message handling.

3. Optimize or parallelize long-running operations where possible

4. Consider Queue Type & Concurrency Requirements

If parallel message processing is required, consider using a Standard queue with an increased maxConcurrency value.

While a FIFO queue technically allows maxConcurrency > 1 (for example, maxConcurrency=10), doing so means messages may not be processed in strict order. Since message ordering is the core feature of FIFO, maintaining maxConcurrency=1 is required to preserve guaranteed ordering. For more info, please refer to a KB Anypoint MQ FIFO Queue Message is not in order if maxConcurrency is not 1