Problem
On the JPA (aggregate-based) event store, a command handler that loads more than one entity, or loads the same entity twice, fails with:
java.lang.UnsupportedOperationException: Not implemented yet
The event store combines the consistency markers of each load, keeping the lower of the two as the safe write position, and the aggregate-based marker never implemented that operation. The same handler works on the in-memory store, so an application only discovers this the first time it runs against a database.
Reproduce
On AggregateBasedJpaEventStorageEngine, send a command to a handler that loads two event-sourced entities, or the same entity twice.
Observed: UnsupportedOperationException("Not implemented yet"), thrown as the second load completes.
Expected: the command succeeds, as it does on the in-memory store.
The defect is deterministic, so the two files below are the re-check.
Suspect
AggregateBasedConsistencyMarker.java:79 -- an unconditional throw, reached from DefaultEventStoreTransaction.java:152 on every sourcing after the first in one processing context.
Possible fix
Implement doLowerBound as the mirror of the existing doUpperBound: take the union of aggregate identifiers and pick, per identifier, the lowest recorded position.
Union, not intersection. An aggregate present in only one marker must keep its position, because the aggregate-based engine derives the next event's sequence number from it. Dropping it would restart that aggregate at sequence 0 and lose its conflict detection.
A literal reading of the ConsistencyMarker Javadoc ("any events beyond either marker are beyond the result") suggests dropping identifiers only one marker knows about. But doUpperBound, the sequencer in the same class, and AggregateBasedJpaEventStorageEngine.combineAggregateMarkers all treat per-aggregate positions as independent dimensions, so union is the consistent reading. Worth confirming that is the intended contract for this marker type.
A second, independent wall behind this one
Fixing the marker does not make multi-entity command handling work on this store. On PostgreSQL, MultiEntityCommandHandlingComponentSuiteIT stops throwing UnsupportedOperationException and then fails with
TooManyTagsOnEventMessageException: An Event Storage engine in Aggregate mode
does not support multiple tags per event
because the event carries two @EventTags and AggregateBasedEventStorageEngineUtils.assertValidTags:47 rejects that by design.
So the marker gap is a real defect worth fixing on its own, but multi-entity handlers remain unsupported on this store for a second reason. That limitation deserves its own issue or a documented statement, depending on whether it is meant to be permanent.
Problem
On the JPA (aggregate-based) event store, a command handler that loads more than one entity, or loads the same entity twice, fails with:
The event store combines the consistency markers of each load, keeping the lower of the two as the safe write position, and the aggregate-based marker never implemented that operation. The same handler works on the in-memory store, so an application only discovers this the first time it runs against a database.
Reproduce
On
AggregateBasedJpaEventStorageEngine, send a command to a handler that loads two event-sourced entities, or the same entity twice.Observed:
UnsupportedOperationException("Not implemented yet"), thrown as the second load completes.Expected: the command succeeds, as it does on the in-memory store.
The defect is deterministic, so the two files below are the re-check.
Suspect
AggregateBasedConsistencyMarker.java:79-- an unconditional throw, reached fromDefaultEventStoreTransaction.java:152on every sourcing after the first in one processing context.Possible fix
Implement
doLowerBoundas the mirror of the existingdoUpperBound: take the union of aggregate identifiers and pick, per identifier, the lowest recorded position.Union, not intersection. An aggregate present in only one marker must keep its position, because the aggregate-based engine derives the next event's sequence number from it. Dropping it would restart that aggregate at sequence 0 and lose its conflict detection.
A literal reading of the
ConsistencyMarkerJavadoc ("any events beyond either marker are beyond the result") suggests dropping identifiers only one marker knows about. ButdoUpperBound, the sequencer in the same class, andAggregateBasedJpaEventStorageEngine.combineAggregateMarkersall treat per-aggregate positions as independent dimensions, so union is the consistent reading. Worth confirming that is the intended contract for this marker type.A second, independent wall behind this one
Fixing the marker does not make multi-entity command handling work on this store. On PostgreSQL,
MultiEntityCommandHandlingComponentSuiteITstops throwingUnsupportedOperationExceptionand then fails withbecause the event carries two
@EventTags andAggregateBasedEventStorageEngineUtils.assertValidTags:47rejects that by design.So the marker gap is a real defect worth fixing on its own, but multi-entity handlers remain unsupported on this store for a second reason. That limitation deserves its own issue or a documented statement, depending on whether it is meant to be permanent.