Skip to content

fix: Do not report a permanent data source failure as fatal - #52

Draft
kinyoklion wants to merge 1 commit into
mainfrom
devin/openfeature-python-non-fatal-data-source-off
Draft

fix: Do not report a permanent data source failure as fatal#52
kinyoklion wants to merge 1 commit into
mainfrom
devin/openfeature-python-non-fatal-data-source-off

Conversation

@kinyoklion

Copy link
Copy Markdown
Member

A permanent data source failure no longer puts the provider into the OpenFeature FATAL state, so the OpenFeature client keeps evaluating against the flag data the LaunchDarkly client already has.

Requirements

  • I have added test coverage for new or changed functionality
  • I have followed the repository's pull request submission guidelines
  • I have validated my changes against all supported platform versions
Implementation details

Related issues

#49 — during an outage, a 401 on an already-established stream took the data source to OFF and OpenFeature evaluations started returning call-site defaults even though the LaunchDarkly client still had valid flag data.

Describe the solution you've provided

The OpenFeature Python SDK short-circuits evaluation when the provider status is FATAL:

if status == ProviderStatus.FATAL:
    return ProviderFatalError()

That means the provider is never asked to evaluate and the call-site default is returned. PROVIDER_FATAL is what moves the provider into that status, so reporting a permanent data source failure that way discards flag data the LaunchDarkly client can still serve. ErrorCode.GENERAL keeps the provider in ERROR, which still surfaces the failure through provider events and get_provider_status() while leaving evaluation intact.

Describe alternatives you've considered

Leaving the state fatal only when the client never initialized was considered. It adds state tracking to the provider for little benefit: a client that never initialized has no flag data, so evaluations already fall back to defaults with a PROVIDER_NOT_READY/ERROR reason, and the ERROR status carries the same signal to anything watching provider events.

Testing

Added test_evaluations_continue_after_the_data_source_permanently_fails, backed by a new InitializedThenFailingDataSource fixture that initializes with flag data, goes VALID, then transitions to OFF with a 401. The test asserts the provider status is ERROR and that the cached flag still evaluates to its real value rather than the call-site default.

Link to Devin session: https://app.devin.ai/sessions/0c452d209ec54b068ba120b4c92b8f6c
Requested by: @kinyoklion

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>
@kinyoklion kinyoklion self-assigned this Aug 19, 2026
@devin-ai-integration

Copy link
Copy Markdown
Contributor

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment, CI, and merge conflict monitoring

@devin-ai-integration devin-ai-integration Bot added the devin-pr Pull request created by Devin AI label Aug 19, 2026
@devin-ai-integration

Copy link
Copy Markdown
Contributor

@cursor review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

devin-pr Pull request created by Devin AI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant