Test fixture trouble

Hi all,

I’m having some trouble with the GivenWhenThenTestFixture – it seems that in some cases no matter what I do, I get the “stored events and published events do not match” error where some events are missing in the “published” list. (Not different, just missing.)

After a lot of old-school logging-based debugging I finally tracked this down to the following bit of code:

public DomainEventMessage onRegisteredEvent(DomainEventMessage event) {
if (registeredAggregates.containsKey(aggregate)) {
event = (DomainEventMessage) invokeEventRegistrationListeners(event);
doPublish(event, eventBus);
}
return event;
}

in DefaultUnitOfWork. Removing the “registeredAggregates.containsKey(…)” check makes everything the event “published” and “stored” lists match.

Does anybody have any hints as to why the check is there and perhaps what’s going on?

I don’t think I’m doing anything strange which would cause the aggregate to not be registered with the unit of work.

Hi Bardur,

this sounds weird. This is the first time I hear about this issue. Could you send the code in which you’re using the fixture? Maybe I see something that might cause this.
Meanwhile, I’ll have a look as to why the check is there. I probably had a good reason at the time.

There is one known issue with the fixtures, which is when you use a specific identifier to load an aggregate, but the loaded aggregate returns another identifier. The errors I got with that problem don’t seem to match this one, though.

Cheers,

Allard

Hi Bardur,

I did a little theoretical exploration to see what could be going on. The only way I see you can get this error, is when you implement a hashCode methods that returns a value based on the aggregate’s state.
Are you implementing an equals/hashCode on you aggregates?

Cheers,

Allard

Hi Bardur,

this sounds weird. This is the first time I hear about this issue. Could you send the code in which you’re using the fixture? Maybe I see something that might cause this.

Unfortunately it’s all proprietary, so I cannot. I’ll see if I can “anonymize” the code sufficiently and create a smaller reproducer example.

Meanwhile, I’ll have a look as to why the check is there. I probably had a good reason at the time.

Thanks. I probably don’t fully understand the DefaultUoW code, but wouldn’t one always expect a generated event to belong to an aggregate registered in the UoW? If so, shouldn’t there be some assertion at “add event” time instead of “silent” checking before publishing?

In fact I think I’ll add such asserts to see if I can track down why the check fails.

There is one known issue with the fixtures, which is when you use a specific identifier to load an aggregate, but the loaded aggregate returns another identifier. The errors I got with that problem don’t seem to match this one, though.

Yeah, I think I’ve run into this with randomly generated identifiers at create time. (Rather than specified in command input.)

We solved it by having a custom event matcher which can ignore certain (specified) fields.

Good idea! That was indeed it – I was using equals() and hashCode() implementations generated by Lombok.

Perhaps this check should be turned into an exception with an explanation for the “does not match” case? (To prevent this issue from happening to others, I mean. It took me quite a while to figure out that events were actively being filtered out because the filtering is silent.)

It also seems a bit odd to check for full equality rather than just identity… is there some other reason for that?

Thanks for your help in any case,

Hi Bardur,

if you update to the latest snapshot (the build is running), your problem should be solved. The check was removed and I included a test to ensure Axon can deal with “bad” (my opinion) hashCode implementations.

Cheers,

Allard

Great, thanks!