CommandExecutionException: OUT_OF_RANGE: [AXONIQ-2000] Invalid sequence number 5 for aggregate , expected 7


Every now and then I’m getting below concurrency exceptions. I’m using AxonServer EE 4.5.7. What may be the reason for this? Noticing this after enabling snapshot using EventCountSnapshotTriggerDefinition(Update : This issue is observed even after clearing events/snaphots and removing snapshot trigger from aggregate. )

org.axonframework.commandhandling.CommandExecutionException: OUT_OF_RANGE: [AXONIQ-2000] Invalid sequence number 5 for aggregate , expected 7
	at org.axonframework.axonserver.connector.ErrorCode.lambda$static$11(
	at org.axonframework.axonserver.connector.ErrorCode.convert(
	at org.axonframework.axonserver.connector.command.CommandSerializer.deserialize(
	at org.axonframework.axonserver.connector.command.AxonServerCommandBus.lambda$doDispatch$2(
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(
	at java.base/java.util.concurrent.CompletableFuture.postComplete(
	at java.base/java.util.concurrent.CompletableFuture.complete(
	at io.axoniq.axonserver.connector.command.impl.CommandChannelImpl$CommandResponseHandler.onNext(
	at io.axoniq.axonserver.connector.command.impl.CommandChannelImpl$CommandResponseHandler.onNext(
	at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onMessage(
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInternal(
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1MessagesAvailable.runInContext(
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.base/java.util.concurrent.ThreadPoolExecutor$
	at java.base/
Caused by: AxonServerRemoteCommandHandlingException{message=An exception was thrown by the remote message handling component: OUT_OF_RANGE: [AXONIQ-2000] Invalid sequence number 5 for aggregate , expected 7, errorCode='AXONIQ-4002', server='8@server-677c89b899-vp667'}
	at org.axonframework.axonserver.connector.ErrorCode.lambda$static$11(
	... 16 more


Also, this error pops up usually after an aggregate event published from a aggregate DeadlineHandler.

    @DeadlineHandler(deadlineName = "deadLine")
    public void handle(DeadlinePayload payload){
        apply(new XYZEvent("id"));


Is Quartz running in cluster mode ( true)?

No, Quartz is not running in cluster mode. Below are the configs used for your reference:

    job-store-type: jdbc
        makeThreadsDaemons: true
        threadCount: 10
        batchTriggerAcquisitionFireAheadTimeWindow: 0
        instanceId: AUTO
        instanceName: deadline-instance
        batchTriggerAcquisitionMaxCount: 20
        idleWaitTime: 60000
        makeSchedulerThreadDaemon: true
        dataSource: xxxx
        acquireTriggersWithinLock: true
        tablePrefix: xxx_
        class: org.quartz.impl.jdbcjobstore.JobStoreCMT
        isClustered: false
        misfireThreshold: 120000
        #clusterCheckinInterval: 20000
        driverDelegateClass: org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
        cleanShutdown: true

Hi @S.Roy

If you have multiple instances of your application running, you should configure the cluster mode isClustered: true . This is very important, but this will not solve the issue you are describing in the logs.

The deadline payload message (handled by the @DeadlineHandler) is not consistently routed to the same application instance that previously handled this aggregate (aggregateIdentifier). Because of this fact, you can update/apply two events for the same aggregate in parallel triggering the optimistic locking mechanism on the event store level. One event will fail with the wrong sequence message because it has a stale sequence number.

One way of solving this is to send a command from your DeadlineHandler (not applying the event directly). Commands are constantly routed to appropriate application instances / Commands with the same aggregate identifier will be sequentially routed to the same application instance.


Thank you @Ivan_Dugalic, Sending a command instead of applying event does solve the issue. But will there be any fix available to consistently route deadline handlers in upcoming releases?

Sure, thank you again for your feedback.


We have an idea to actually replace QUARZ and implement scheduling on our own (Axon Server). One part of this would involve the consistent routing of deadlines. I am not sure if this idea is already drafted as a concrete plan and included in the roadmap, TBH.

For now, I would suggest sending a command. This feature will be discussed internally in the upcoming weeks and we might give it more priority. I will keep you informed.