[#4799] Align the autoconfigured JPA gap defaults with the core defaults - #4821
Merged
Conversation
The two @DefaultValue annotations carried each other's value, so a Spring Boot application that set no axon.eventstorage.jpa.* property got a 10000 ms gapTimeout and a 60000-entry maxGapOffset where AggregateBasedJpaEventStorageEngineConfiguration.DEFAULT uses 60000 ms and 10000. The enhancer copies every property onto the core configuration unconditionally, so the swap always won over the core default. The short timeout is the harmful direction: it is the window a not-yet-committed event has to become visible before a streaming consumer gives up on it, and nearly every production JPA application reaches the engine through this path. The migration guide restated the same swapped pair as the documented defaults, and its included sample repeated those numbers against the core builder where they are not the defaults either, so both are corrected with it. Fixes #4799
schananas
requested review from
hjohn,
jangalinski and
smcvb
and removed request for
a team
July 29, 2026 15:46
smcvb
added
Priority 1: Must
smcvb
approved these changes
Aug 6, 2026
smcvb
left a comment
smcvb
left a comment
Contributor
There was a problem hiding this comment.
What a catch...Looks good to me 👍
Contributor
|
/backport axon-5.3.x |
Contributor
|
Successfully created backport PR for |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4799
What changed
The two
@DefaultValueannotations onJpaEventStorageEngineConfigurationPropertiescarried each other's value:gapTimeoutmaxGapOffsetThe short timeout is the harmful direction. It is the window a not-yet-committed event has to become visible before a streaming consumer gives up on it, and nearly every production JPA application reaches the engine through Spring Boot.
The swap always won:
JpaEventStoreAutoConfiguration.AggregateBasedJpaEventStorageEngineConfigurationEnhancer:103-110copies every property onto the core configuration unconditionally, so an application could not fall through to the correct core default even by setting nothing.Docs are in the commit on purpose
The same swapped pair is published as the documented defaults:
migration/pages/paths/event-store.adoc:453,458statesgap-timeout=10000andmax-gap-offset=60000as "the default".customconfig/AxonConfig.java:37,40repeats those numbers against the core builder, where they are not the defaults either.Tests
JpaEventStorageEngineConfigurationPropertiesTest, 4 testcases, 0 failures. PlusJpaAutoConfigurationTest(2), the class that exercises the autoconfig path.Reverting just the two
@DefaultValueswaps fails withexpected: 60000 but was: 10000andexpected: 10000 but was: 60000.The test asserts against
AggregateBasedJpaEventStorageEngineConfiguration.DEFAULTrather than literals, so the two paths cannot drift apart again silently, and a third case covers all five shared settings.For the reviewer
The effective default moves for every Spring Boot JPA application that never set these properties: tokens get smaller and gaps live longer. Worth checking whether any downstream test or benchmark depended on the 10000 ms timeout.
No behaviour change for anyone who set either property explicitly, which the new test also pins.
Related: this is the same
gapTimeoutmechanism as the event-skipping problem, so the two interact.Not a pure safety win in both directions
gapTimeout10000 to 60000 is safer: gaps survive longer, so fewer committed events are skipped. It costs bigger tracking tokens and more gap re-querying.maxGapOffset60000 to 10000 is less forgiving: a token now abandons gaps more than 10000 behind the highest index instead of 60000. Aligning with the core record is still the right call, but only one half of this change is strictly safer.This is an upgrade-time behaviour change for every Spring Boot JPA application that never set these properties, so it needs a release note.