fix: Do not report a permanent data source failure as fatal - #52
Draft
kinyoklion wants to merge 1 commit into
Draft
fix: Do not report a permanent data source failure as fatal#52kinyoklion wants to merge 1 commit into
kinyoklion wants to merge 1 commit into
Conversation
Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
Contributor
|
@cursor review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A permanent data source failure no longer puts the provider into the OpenFeature
FATALstate, so the OpenFeature client keeps evaluating against the flag data the LaunchDarkly client already has.DataSourceState.OFFnow emitsErrorCode.GENERALinstead ofErrorCode.PROVIDER_FATALERRORRequirements
Implementation details
Related issues
#49 — during an outage, a
401on an already-established stream took the data source toOFFand 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:That means the provider is never asked to evaluate and the call-site default is returned.
PROVIDER_FATALis 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.GENERALkeeps the provider inERROR, which still surfaces the failure through provider events andget_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/ERRORreason, and theERRORstatus carries the same signal to anything watching provider events.Testing
Added
test_evaluations_continue_after_the_data_source_permanently_fails, backed by a newInitializedThenFailingDataSourcefixture that initializes with flag data, goesVALID, then transitions toOFFwith a401. The test asserts the provider status isERRORand 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