Flaky Behavior for Dynamic Conversion

[dilgerma]

Basic information

This is a custom quarkus extension but the behavior might be due to the dynamic conversion in Axon 5.x.

• Axon Framework version: 5.1.0

• JDK version: 21 (observed on the reproducer branch)

• Complete executable reproducer if available (e.g. GitHub Repo):

  • Reproducer branch: https://github.com/meks77/quarkus-axonframework-extension/tree/axon-51-upgrade-flaky-exception

Steps to reproduce

1. Check out the reproducer branch:
   axon-51-upgrade-flaky-exception
2. Navigate to the core/deployment Maven module (quarkus-axon-deployment).
3. Execute the test class:
   at.meks.quarkiverse.axon.deployment.eventprocessors.pooled.WithDefaultsTest
4. Run the test repeatedly.

The issue is flaky and does not occur on every execution. After several runs, the test may fail with an exception originating from the PooledStreamingEventProcessor / WorkPackage processing flow.

Expected behaviour

The test should complete successfully on every execution without exceptions during event processing.

Actual behaviour

The test intermittently fails with the following exception:

java.lang.IllegalArgumentException: java.lang.NullPointerException:
Cannot invoke "java.lang.Number.longValue()" because the return value of
"sun.invoke.util.ValueConversions.primitiveConversion(sun.invoke.util.Wrapper, Object, boolean)"
is null

The exception is logged from:

org.axonframework.messaging.eventhandling.processing.streaming.pooled.WorkPackage

Example log message:

WARN  [org.axonframework.messaging.eventhandling.processing.streaming.pooled.WorkPackage]
(WorkPackage[GiftCardInMemory]-0)
Error while processing batch in Work Package [2]-[GiftCardInMemory].
Aborting Work Package...

The stack trace indicates the failure occurs during event handler invocation through MethodInvokingMessageHandlingMember, eventually causing the WorkPackage to abort processing.

A complete stack trace is available in the issue description above.

[markushager-itsv]

I have additional information.
My colleague could in the mean time reproduce this error every time on a different branch using another test, where we use an axon server without dcb.
The EventHandler at.meks.quarkiverse.axon.shared.projection.GiftcardInMemoryHistory#handle(at.meks.quarkiverse.axon.shared.model.Api.CardIssuedEvent, long) gets the SequenceNumber injected. Because it is the primitive, and the value is null, the framework runs into a NPE.

For me it seems to be a bug. In our product we are using the sequnce number rarly, so we could workaround that, investing some amout of time.

[smcvb]

We are quiet confident that this problem has been resolved with #4670 . Awaiting final judgement from @markushager-itsv and team if that's the case.

We'll get conclusion on this once 5.1.2. has been released. As such, this issue is still point to 5.2.0, to be validated once 5.1.2 is released.

[markushager-itsv]

I am sorry for the late response. I can approve that the error was fixed.