Hi, Tobias' observation is correct. RetryConfig was always meant to be configurable, it already has the necessary annotations, but it effectively is not, as PersistenceParams.retryConfig() is a Java default function, which SmallRye config "ignores."
I wouldn't mind seeing the PersistenceParams interface changed (aka retryConfig() not being a default function, while BuildablePersistenceParams.retryConfig() can stay a default function). I'm happy to review a change for that. Robert On Tue, Oct 13, 2026 at 9:28 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Tobias, > > Great analysis and thanks for the reproducer in TestRetryLoopImpl. > > It seems you found some kind of inconsistency :) > > I don't see an intentional reason for the NoSQL retry config to be fixed > (I'm sure Robert has some insights about that). JDBC already exposes > max-retries, max-duration and initial-delay, so exposing the same in NoSQL > would be consistent. I think a PR would make sense for that. > > Having 30s for read-timeout and server-selection-timeout with 15s retry > budget means we can have a stalled attempts without retry (as you > described). I would treat that as a doc "issue" :) Once the budget is > configurable, we can align the defaults and document. > > I'm not sure we should change the per-attempt deadline: it basically > changes the retry logic, it's not just a configuration update. I believe > the Mongo driver already has its own timeouts (bound to an attempt). I > would suggest to keep it out of the config PR and discuss it > separately. @Robert, as you know better than me the NoSQL retry design, > could you weigh in on whether the total-budget-only model was intentional? > > Anyway, I'm happy your clients retry successfully and nothing is lost :) > > Regards > JB > > On Mon, Oct 12, 2026 at 1:01 PM Tobias Riemenschneider < > [email protected]> wrote: > > > Hi all, > > > > We run Polaris 1.8.0 with the NoSQL (MongoDB) persistence and saw the > > pattern below on 1.7.0; the relevant code is unchanged in 1.8.0 and main. > > I'd like to check it against the intended design before filing an issue. > > > > *What we see:* when MongoDB stalls for about 15 s (for example w:majority > > writes behind a lagging secondary), table commits fail with > > > > RetryTimeoutException: Retry timeout after PT15.002S, 0 retries > > > > and clients get a 500. The commits are retried by our client and no data > is > > lost, so this is low impact for us. > > > > *Why, as far as I can tell:* RetryLoopImpl checks the total budget ( > > RetryConfig.timeout, default PT15S) only after an attempt has ended, and > > nothing bounds a single attempt. A stalled first attempt therefore leaves > > no budget for a second one. I reproduced this with a unit test in > > TestRetryLoopImpl on main (simulated clock, default config). The > relational > > JDBC withRetries has the same single-attempt behaviour, so I assume that > > part is by design. I checked this comparison and the config reference > > against both main and the 1.8.0 tag. > > > > *Two things look inconsistent to me:* > > > > 1. The NoSQL retry config cannot be changed. I found no > > polaris.persistence.retry* property in the config reference, and > > PersistenceParams.retryConfig() returns the constant default, while > the > > JDBC persistence exposes max-retries, max-duration-in-ms and > > initial-delay-in-ms. > > 2. The helm docs recommend quarkus.mongodb.read-timeout: 30S and > > server-selection-timeout: > > 30S. Both are longer than the 15 s budget, so with the documented > > settings a stalled attempt can only end after the budget is gone. > > > > > > *Questions:* > > > > - Is the retry config intentionally not configurable? > > - Is the 30 s driver timeout recommendation meant to go together with > > the 15 s budget, or should one of them change? > > - Would a per-attempt deadline (a fraction of the total budget) be > > welcome, or is the total-budget-only model intended? > > > > > > If exposing the retry config as properties (like JDBC) is acceptable, I'm > > happy to send a PR. > > > > I used AI assistance to analyse the code and draft this message; I have > > reviewed it. > > > > Best regards, > > > > *Tobias Riemenschneider* > > > > Sr. Lead Software Engineer > > > > [email protected] > > Cumulocity GmbH, Software Center 5b, 35037 Marburg, Germany > > < > https://www.google.com/maps/search/Software+Center+5b,+35037+Marburg,+Germany?entry=gmail&source=g > > > > > > -- > > > > > > > > > > > > Website <https://www.cumulocity.com> | Linkedin > > <https://www.linkedin.com/company/cumulocity/> > > > > > > > > >
