fix: Map the WRONG_TYPE error kind to TYPE_MISMATCH - #27
Merged
Conversation
Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>
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 |
keelerm84
approved these changes
Sep 1, 2026
kinyoklion
added a commit
that referenced
this pull request
Sep 1, 2026
Adds a feature matrix to the README, mirroring the OpenFeature PHP SDK's own matrix, so a reader can see at a glance what this provider does and does not do. - Most unsupported rows are limitations of the OpenFeature PHP SDK, not of this provider — eventing, shutdown, named clients, tracking, transaction context and flag metadata have no place in that SDK's provider interface — and each row says so, so they are not read as provider gaps. - Format matches the matrices added to the Java, Python, .NET and JavaScript providers this week, so the providers can be compared side by side. <details> <summary>Implementation details</summary> Rows and statuses were checked against the OpenFeature PHP SDK 2.3.0 and the LaunchDarkly PHP SDK 6.8.3 rather than copied from another provider: `OpenFeature\interfaces\provider\Provider` declares only the five `resolve*Value` methods plus hooks, logger and metadata accessors, `ProviderAware` holds a single provider for the whole API, and neither `EvaluationDetails` nor `ResolutionDetails` carries flag metadata. The three separate fixes opened alongside this (#27, #28, #29) are provider-side bugs within rows the matrix marks as supported, so they do not change any status here. **Requirements** - [x] I have added test coverage for new or changed functionality - [x] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [x] I have validated my changes against all supported platform versions **Related issues** None. **Describe the solution you've provided** A `## Feature matrix` section after the supported-versions section, with the same `Status | Feature | Notes` shape as the other LaunchDarkly OpenFeature providers. **Describe alternatives you've considered** Listing only the rows the OpenFeature PHP SDK's own matrix has: it would drop initialization, tracking, transaction context and flag metadata, which are exactly the rows readers coming from another LaunchDarkly provider will look for. **Additional context** Testing: documentation only; `make check` still passes. </details> Link to Devin session: https://app.devin.ai/sessions/38a6eaf69fcf41109e136a1d0fe5e899 Open in Devin Desktop: https://app.devin.ai/desktop/session/38a6eaf69fcf41109e136a1d0fe5e899?variant=devin Requested by: @kinyoklion <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Overview** > Adds a **Feature matrix** section to the README (after supported PHP versions), aligned with the [OpenFeature PHP SDK feature list](https://github.com/open-feature/php-sdk#-features) and the same table shape used on other LaunchDarkly OpenFeature providers. > > The table lists each capability with ✅/❌ status and notes: supported areas (flag types, targeting, hooks, logging, MultiProvider, extending via `LDClient`) and unsupported rows that call out whether the gap is the OpenFeature PHP SDK (e.g. named clients, eventing, shutdown, tracking, transaction context, flag metadata) versus provider behavior. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit da8803a. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
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.
Maps the LaunchDarkly
WRONG_TYPEevaluation error kind to the OpenFeatureTYPE_MISMATCHerror code.GENERAL, so an application could not distinguish a flag whose type does not match the requested one from any other evaluation error.OFPrequirement 3.2.3 prescribes this mapping, and the Java, .NET, Python, Ruby and JavaScript providers all implement it.Implementation details
Requirements
Related issues
None. The same gap was fixed this week in openfeature-python-server#57 and js-core#1888.
Describe the solution you've provided
ResolutionDetailsConverter::errorKindToCodegains the missing case. The LaunchDarkly PHP SDK reports this kind when a flag's value does not match the requested type, which OpenFeature represents asTYPE_MISMATCH.Describe alternatives you've considered
None; the mapping is prescribed by the provider spec.
Testing
make check(composer cs-check,composer phpstan,composer phpunit). The new test drives the converter directly, since the provider's own type checking intercepts most mismatches before the SDK reports this kind.Link to Devin session: https://app.devin.ai/sessions/38a6eaf69fcf41109e136a1d0fe5e899
Open in Devin Desktop: https://app.devin.ai/desktop/session/38a6eaf69fcf41109e136a1d0fe5e899?variant=devin
Requested by: @kinyoklion
Note
Overview
When the LaunchDarkly SDK returns an evaluation error with kind
WRONG_TYPE_ERROR, the OpenFeature provider now surfacesTYPE_MISMATCHinstead of the genericGENERALcode.ResolutionDetailsConverter::errorKindToCodegains the missing switch case so callers can tell a wrong flag type apart from other evaluation failures, matching OpenFeature provider spec 3.2.3 and the other LaunchDarkly OpenFeature SDKs.A new unit test exercises the converter directly with
EvaluationReason::error(WRONG_TYPE_ERROR)and assertsReason::ERRORplusErrorCode::TYPE_MISMATCH().Reviewed by Cursor Bugbot for commit 7fe8ed8. Bugbot is set up for automated code reviews on this repo. Configure here.