[XieX]

What

AIC-3600. init_client() built the LaunchDarkly client with start_wait=10 and adopted it without checking whether it had initialized. The SDK constructor returns normally both when that wait runs out and when the service rejects the SDK key; it only logs. So a bad key or an unreachable LaunchDarkly gave the app no error at startup, and every AI Config was served disabled.

Reproduced on main against a local server answering 401 and against a closed port: init_client returned, is_initialized() was False, and inspect_config returned {'enabled': False, 'config': None, 'meta': None}. With the locked launchdarkly-server-sdk 9.18.3 both cases take the full 10 s, since that version keeps retrying after a 401; older versions such as 9.16.0 give up on a 401 at once.

Change

• After building the client (and after the existing check for a concurrent call that won), init_client checks is_initialized(). When it is false, it closes the client and raises RuntimeError("LaunchDarkly client failed to initialize: …"), naming the SDK key and reachability as the things to check. Nothing is cached, so a later call retries.
• A client passed as client= is not checked: the caller owns its readiness.
• The close-and-ignore-errors block, now needed in three places, is one helper, _close_quietly. An error from close cannot replace the initialization error.
• README: the lifecycle table and the "fail fast at boot" list say init_client raises in this case.
• README: a note that a failed init is not cached, so while LaunchDarkly is unreachable every lazy call, inspect_config included, waits up to 10 seconds and concurrent calls each build their own client. Calling init_client() at startup keeps that out of request handling. A shared in-flight attempt, as TypeScript has, would bound the concurrent case; that is a separate change.

This matches the JavaScript and Go SDKs, which already fail here. Spec: launchdarkly/ai-sdks-monorepo#123.

Behavior change: an app that used to start with a bad key or no network now gets an exception from init_client(), or from the first config().invoke() when init is lazy. inspect_config still returns the disabled fallback and never raises.

Tests

• test_an_sdk_client_that_did_not_initialize_fails_the_call: the first client reports itself uninitialized. The call raises, that client is closed, get_client() still raises, and a retry with a healthy client succeeds.
• test_a_close_error_does_not_replace_the_initialization_error: close raising still surfaces the initialization error and leaves no client.
• test_does_not_check_whether_a_passed_client_initialized: a BYOC client reporting False is adopted and is_initialized is never called.

The first two fail without the fix. make lint, make format-check, make typecheck, make api-report-check and make test pass. Rerunning the repro now raises in both cases.

🤖 Generated with Claude Code

---

Note

Overview
init_client() now fails loudly when the auto-built LaunchDarkly SDK client reports is_initialized() as false (timeout after 10s, rejected SDK key, or unreachable service). Previously the constructor returned normally and the app could run with every AI Config effectively disabled.

On failure the client is closed via new helper _close_quietly (also used when losing a concurrent init race or when telemetry setup fails), nothing is cached as the singleton, and a RuntimeError points at LD_SDK_KEY and reachability. A later init_client() call retries. Clients passed with init_client(client=...) are unchanged—the caller owns readiness and is_initialized() is not checked.

README documents startup fail-fast, lazy-init retry behavior (including up to 10s waits per lazy attempt during outages), and updated API table entries.

Tests cover uninitialized SDK clients, close errors not masking the init error, and BYOC skipping the check.

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

[jeffdupont]

Approving. The is_initialized() check, close-on-failure and the _close_quietly helper do what AIC-3600 asks, and I confirmed the three new tests plus the rest of test_lifecycle.py pass (67).

One thing before merge: this changes startup behavior (a bad key or no network used to start fine, now init_client() raises), but the title is fix(client). release-please will cut a patch release with no breaking note. Could you retitle it fix(client)!: or add a BREAKING CHANGE: footer, as the 0.5.0 changelog does?

Optional: the new error is a plain RuntimeError, the same type as "no SDK key" and "SDK not installed", so a caller can't separate "LD unreachable, retry later" from "misconfigured". The spec only asks for a rejection, so I'm fine leaving it.