[tanderson-ld]

Summary

LDClient's constructor converted config.startWait to milliseconds with Duration.toMillis(), which throws ArithmeticException for a duration too large to represent in milliseconds (longer than ~292 million years — e.g. Duration.ofSeconds(Long.MAX_VALUE)). The conversion ran after dataSystem.start(), so the exception escaped the constructor with the data system already started (streaming connection, threads, event processor) and no reference available to close it — leaking the client on every construction attempt.

Fix

The start wait is converted inside the wait block, clamping a value at or beyond the largest representable millisecond duration (Duration.ofMillis(Long.MAX_VALUE)) to Long.MAX_VALUE rather than converting it:

long startWaitMillis = config.startWait.compareTo(MAX_MILLIS_START_WAIT) >= 0
    ? Long.MAX_VALUE
    : config.startWait.toMillis();

A threshold comparison is used rather than catching the ArithmeticException so the clamp reads as deliberate; the boundary is definitional (ofMillis(Long.MAX_VALUE) is by definition the largest representable millisecond duration), and computing inside the !isZero() && !isNegative() block means only the positive overflow boundary is ever in play.

A start wait that large already behaved as the maximum representable wait at the boundary value, so this adds no new behavior — it only replaces the overflow-and-leak with that existing bounded maximum. Normal values are unaffected; Duration.ZERO/negative still mean "don't wait".

Notes

Clamping to a definite maximum (rather than treating an over-large wait as indefinite) is consistent with the start-wait contract across the server SDK fleet, which model start-wait as a bounded timeout with no "wait indefinitely" mode. (Indefinite initialization waiting exists only in the OpenFeature providers, by OpenFeature-provider-spec requirement, and is handled entirely at the provider layer.)

Found during the OpenFeature Java provider start-wait review. SDK-3418.

Test

LDClientTest.startWaitTooLargeForMillisIsClampedRatherThanOverflowing asserts the clamped Long.MAX_VALUE reaches initFuture.get(...); reverting the clamp fails it with ArithmeticException: long overflow. Full LDClientTest, LDClientOfflineTest, LDClientEndToEndTest and checkstyle pass.

---

Note

Overview
Fixes LDClient constructor startup when LDConfig.startWait is too large to convert to milliseconds. The code previously called config.startWait.toMillis() after dataSystem.start(), which can throw ArithmeticException and leave the data system running without a usable client reference.

LDClient now compares startWait to Duration.ofMillis(Long.MAX_VALUE) and uses Long.MAX_VALUE when the configured wait is at or above that boundary; otherwise it still uses toMillis(). Logging, the excessive-wait warning, and startFuture.get(...) all use this clamped startWaitMillis. Zero and negative start waits are unchanged (still skip waiting).

Adds LDClientTest.startWaitTooLargeForMillisIsClampedRatherThanOverflowing, which expects initFuture.get(Long.MAX_VALUE, TimeUnit.MILLISECONDS) for Duration.ofSeconds(Long.MAX_VALUE) instead of failing on overflow.

^{Reviewed by Cursor Bugbot for commit 6645f04. Bugbot is set up for automated code reviews on this repo. Configure here.}