LD cache bypass after data source 401

[fvigneault]

Describe the bug
During the LaunchDarkly outage of July 10th, 2026, OpenFeature evaluations immediately started returning the call-site default value, even though the underlying LaunchDarkly SDK still had initialized/cached flag data available.

This appears to happen because the OpenFeature provider transitions to ProviderStatus.FATAL when the LaunchDarkly stream connection receives an HTTP 401 (invalid SDK key), and then short-circuits before calling the LaunchDarkly client for evaluation.

To reproduce

1. Start with a valid SDK key and allow the provider to initialize and cache flag data.
2. Verify evaluations are working:
   • Direct LaunchDarkly client evaluation returns expected targeted value.
   • OpenFeature evaluation returns the same value.
3. Trigger stream failure with HTTP 401 (invalid SDK key) on the already-established stream connection.
4. Observe:
   • LaunchDarkly SDK data source transitions to OFF and stops reconnecting (expected for unrecoverable 401).
   • LaunchDarkly SDK feature store remains initialized with cached data.
   • OpenFeature provider status becomes ProviderStatus.FATAL.
   • Subsequent OpenFeature evaluations return the default value immediately.

Observed behavior

• Before OFF/401:
  • direct LD: True
  • OpenFeature: True
• After OFF/401:
  • direct LD: True (from cached data)
  • OpenFeature: False (call-site default)
  • OpenFeature provider status: ProviderStatus.FATAL

From tracing, OpenFeature evaluation appears to return early on provider fatal status (e.g. _assert_provider_status()), so LaunchDarklyProvider.resolve_*() / LDClient.variation_detail() is not called, and LD cached data is never consulted.

Expected behavior
After stream 401 transitions the LD data source to OFF, OpenFeature should ideally still allow evaluations against cached LaunchDarkly data (or provide a configurable behavior), rather than always returning defaults due to provider fatal short-circuiting.

At minimum, users need a way to preserve “last known good” flag behavior in this scenario.

Logs
The stream reported:

Received HTTP error 401 (invalid SDK key) for stream connection - giving up permanently

SDK version

• launchdarkly-openfeature-server==0.5.1
• LaunchDarkly Python server SDK: 9.15.1

Language version, developer tools

• Python (server-side, OpenFeature provider integration)

OS/platform

• Reproduced in Linux containerized runtime (Kubernetes pods)

Additional context
This behavior caused immediate fallback to defaults across running clients during LaunchDarkly outage conditions, rather than only affecting newly started clients. The key point is that LD cached targeting data still existed, but was bypassed by the OpenFeature provider status handling.

[jsonbailey]

@fvigneault thank you for reporting this. We are reviewing how our SDKs respond to 401s and will include how this cascades to OpenFeature in our discussions.