4.10.0 aggregate test failure, passes in 4.10.1

Hi,

I have a question about aggregate test failure in version 4.10.0. To keep it short, here is an example:

   @Test
    public void shouldNotRunSameCommand() {
        fixture.given(scanReceivedEvent)
                .when(scanCommand)
                .expectNoEvents();
    }

This same test fails in 4.10.0, but passes in 4.10.1

Any comments as to what has changed?


Seems like some combination of given → event sourced event and the command that applies the same event sourced event, results with weird behavior.

Thanks.

Welcome to the forum, @Dimitar!
Let’s dive into your scenario right away.

The shouldNotRunSameCommand() test case you’ve written makes an assumption about the Test Fixtures that isn’t correct I am afraid.

The AggregateTestFixture is intended to validate the behavior of a single Aggregate type and instance in action.
The test case you’ve written assumes that the scanCommand is ignored because the aggregate constructed out of the scanReceivedEvent already exists.

You would make the test run successfully if the @CommandHandler annotated method is a none-constructor command handler with the @CreationPolicy(CREATE_IF_MISSING) annotation attached to it.
By doing so, you more clearly signal Axon Framework that you want the command handler to check for aggregate uniqueness based on the aggregate identifier.

Differently put, the Test Fixture cannot correlate your given event with the “new” command, as they seem unrelated to it.

Granted, I do have two remarks:

  1. I don’t think that the EventStoreException you get to be very clear. We could improve in that area.
  2. I find it pretty odd that your test fails in 4.10.0 but succeeds in 4.10.1… I have been checking the release notes of 4.10.1 and commit history of the AggregateTestFixture, but can’t find any clear reasoning why you’ve spotted this behavior.

At any rate, I do believe you have an answer for what to do. If you feel like investigating the scenario that it works for 4.10.1 but doesn’t for 4.10.0, I would gladly hear your future findings!

Hi Steven,

Thanks for the reply.

I guess the following check cannot be in the constructor, as it will always be null. So, all clear there.

 @CommandHandler
    public ScanAggregate(Commands.ReceiveScanCommand command) {
        log.info("ScanAggregate: scan received command: [{}]", command);

        if (this.scanId != null) {
            log.warn("ScanAggregate: Already initialized");
           // return;
        }

        apply(Events.ScanReceivedEvent.builder()
                .scanId(command.scanId)
                .hardwareId(command.hardwareId)
                .scanTime(command.scanTime)
                .build());
    }

However, difference in behavior in different versions is still confusing and requires further investigation!


For now, I have a check in the event sourcing handler, if not initialized, initialize, else log the warning.

Yep, that’s a correct assumption, @Dimitar!

I similarly agree with you on this point. :sweat_smile:

Sounds like you have a way forward, great :+1:
If you have any questions in the future, be sure to check in to the forum again!

Thanks for the answer!

When I thought about it, my check in event sourcing handler is also useless, as duplicate constructor invocation should result in some kind of an exception.

Other than that, different behavior in different versions seems to be the only issue.