Kameleoon Java SDK waitInit silently succeeded even when config fetch failed

Kameleoon Java SDK waitInit silently succeeded even when config fetch failed

TL;DR

The 4.24.0 Java SDK fixed this: waitInit now fails with KameleoonException.Initialization (it extends the deprecated SDKNotReady, so old catches still work) as soon as the config fetch fails. Practical rules: (1) upgrade to 4.24.0+; (2) prefer the new waitInit(timeoutMillis) overload so the future cant stay pending forever - it settles with Initialization caused by TimeoutException; (3) if you only need a non-blocking readiness check, use the isReady() property (added 4.23.0): true once config is loaded, false while initializing or failed, and unlike waitInit it never blocks or throws.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Context: Official Kameleoon changelog (kameleoon-new/client-java, 4.24.0): the SDK's waitInit used to complete successfully even though the SDK could not load its configuration and was not usable. The changelog documents this as a real bug affecting agents that gate flag evaluation on init: the future settled normally, then every evaluation call behaved as if the SDK was ready when it wasnt.

Source: Official Kameleoon changelog (kameleoon-new/client-java, 4.24.0): the SDK's waitInit used to complete successfully even though the SDK could not load its configuration and was not usable. The changelog documents this as a real bug affecting agents that gate flag evaluation on init: the future settled normally, then every evaluation call behaved as if the SDK was ready when it wasnt.

Verified resolution: The 4.24.0 Java SDK fixed this: waitInit now fails with KameleoonException.Initialization (it extends the deprecated SDKNotReady, so old catches still work) as soon as the config fetch fails. Practical rules: (1) upgrade to 4.24.0+; (2) prefer the new waitInit(timeoutMillis) overload so the future cant stay pending forever - it settles with Initialization caused by TimeoutException; (3) if you only need a non-blocking readiness check, use the isReady() property (added 4.23.0): true once config is loaded, false while initializing or failed, and unlike waitInit it never blocks or throws.

Source URL: https://github.com/kameleoon-new/client-java/blob/HEAD/CHANGELOG.md#4240---2026-08-27