[#4583] fix(messaging): SplitTask leaves token store inconsistent after segment split

[MateuszNaKodach]

closes #4583

Bug description

Introduced in: commit 185c4332 — "When splitting and merging tokens, update both tokens involved"

Before persistent segment masks were introduced, SplitTask only needed to insert the sibling segment and call releaseClaim(original) to release ownership. When that commit added support for updating the original segment's mask, it appended deleteToken(original) + initializeSegment(original with new mask) after the existing releaseClaim rather than replacing it:

releaseClaim(original)   ← sets owner = NULL
deleteToken(original)    ← DELETE WHERE owner = nodeId → 0 rows → UnableToClaimTokenException
initializeSegment(...)   ← never reached

MergeTask has the same problem in its mergeSegments() method: after initializeSegment(mergedSegment) creates the merged token with owner = NULL, the code called releaseClaim(merged), which again matches zero rows and throws UnableToClaimTokenException, preventing the coordinator from reclaiming the merged segment.

The InMemoryTokenStore (used in all existing unit tests) has a no-op releaseClaim and ignores ownership in deleteToken, so both bugs were invisible to the test suite and only surfaced against a real JDBC or JPA token store.

---

What was fixed

SplitTask.splitAndRelease() — releaseClaim() was removed entirely and the operation order corrected:

1. initializeSegment(sibling) — insert sibling with owner = NULL
2. deleteToken(original) — DELETE while owner = nodeId still holds
3. initializeSegment(original with new mask) — re-insert with owner = NULL, ready for reclaiming

MergeTask.mergeSegments() — releaseClaim() was removed. After the two source tokens are deleted and the merged token is initialized with owner = NULL, no claim release is needed — the coordinator picks it up on the next cycle.

JpaTokenStore.deleteToken() (found thanks to the new integration tests) — A secondary issue specific to JPA: after a JPQL bulk DELETE the Hibernate identity map still holds the deleted TokenEntry, causing NonUniqueObjectException when initializeSegment calls em.persist() with the same PK in the same persistence context. Fixed by calling em.flush() + em.clear() after executeUpdate() to evict the stale entry.

---

Tests introduced

Unit — SplitTaskTest (existing class updated):

• Removed releaseClaim mock setup and verification from existing tests; added verify(never()).releaseClaim()
• Added a new test asserting the exact operation order: initializeSegment(sibling) → deleteToken → initializeSegment(original)

Unit — MergeTaskTest (existing class updated):

• Removed releaseClaim mock setup and verification from existing tests; added verify(never()).releaseClaim()

Integration — new Spring Boot IT suite against real token stores:

It's a cornerstone for better test coverage, providing more valuable end-to-end tests of PooledStreamingEventProcessor.

PooledStreamingEventProcessorTestSuite (added to messaging test-jar, no Spring dependency) holds all test logic. It requires subclasses to implement only a buildProcessor() factory method, making it reusable outside Spring contexts. Each test creates its own processor with a UUID-based name for natural token store row isolation — no schema teardown or context reset needed.

PooledStreamingEventProcessorSpringTestSuite (in spring-boot-autoconfigure) is a thin Spring subclass that builds the processor from components obtained via @Autowired AxonConfiguration.

Two concrete IT classes run the full suite against HSQLDB in-memory:

• PooledStreamingJdbcTokenStoreIT — overrides the JPA token store with a JdbcTokenStore bean
• PooledStreamingJpaTokenStoreIT — uses full JPA autoconfiguration with ddl-auto=create-drop

The suite covers two scenarios against both token stores:

• WhenSplittingSegments — calls processor().splitSegment(0) end-to-end and asserts both resulting segments become active, directly reproducing the original bug
• WhenMergingSegments — splits first, then calls processor().mergeSegment(0) and asserts the merged segment becomes active, reproducing the symmetric MergeTask bug

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE