fix: Map the WRONG_TYPE error kind to TYPE_MISMATCH - #57
Merged
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 |
devin-ai-integration
Bot
force-pushed
the
devin/1787756021-python-wrong-type-error
branch
from
August 26, 2026 15:02
6e90243 to
20eada9
Compare
kinyoklion
marked this pull request as ready for review
August 28, 2026 21:40
keelerm84
approved these changes
Aug 31, 2026
kinyoklion
pushed a commit
that referenced
this pull request
Aug 31, 2026
🤖 I have created a release *beep* *boop* --- ## [0.7.0](0.6.0...0.7.0) (2026-08-31) ### Features * Populate OpenFeature flag metadata from the evaluation reason ([#53](#53)) ([11ae1a6](11ae1a6)) * Report provider name and version to LaunchDarkly ([#51](#51)) ([4290b8a](4290b8a)) * Support OpenFeature tracking ([#50](#50)) ([9395775](9395775)) ### Bug Fixes * Do not report a failed initialization as a fatal error ([#56](#56)) ([946a515](946a515)) * Do not report a permanent data source failure as fatal ([#52](#52)) ([15014c1](15014c1)) * Map the WRONG_TYPE error kind to TYPE_MISMATCH ([#57](#57)) ([17478dc](17478dc)) ### Documentation * Add an OpenFeature feature matrix to the README ([#58](#58)) ([6c31554](6c31554)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Overview** > This is a **Release Please** cut that moves the project from **0.6.0** to **0.7.0** by updating version fields in `pyproject.toml`, `ld_openfeature/version.py`, `docs/conf.py`, and `.release-please-manifest.json`. > > It also **adds the 0.7.0 section to `CHANGELOG.md`**, which documents what ships in this release (not new code in this diff): OpenFeature **tracking**, **flag metadata from evaluation reason**, **provider name/version** sent to LaunchDarkly, fixes for **non-fatal** failed init and permanent data-source failures, **`WRONG_TYPE` → `TYPE_MISMATCH`** mapping, and a README **OpenFeature feature matrix**. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 12fafea. 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: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
3 tasks
kinyoklion
added a commit
that referenced
this pull request
Aug 31, 2026
Adds a `start_wait` parameter to `LaunchDarklyProvider`, defaulting to the LaunchDarkly SDK's five seconds. Closes [#55](#55). - The value is passed to `LDClient(config, start_wait)` and bounds the whole of initialization once: with a positive value `initialize` reports the outcome the constructor already waited for rather than waiting again, so a five second start wait cannot become a ten second wait for `set_provider_and_wait`. - Initialization fails when the client did not become ready in time; the provider keeps reporting status afterward, so a later connection still makes it ready. - Zero does not block the constructor at all, and `initialize` then waits without a deadline for the data source to become valid or to fail permanently. - Flips the README feature matrix's Initialization row to supported, since this is the change that makes it true. <details> <summary>Implementation details</summary> ```python # With a start wait the client constructor has already waited, so the outcome is whatever it is now. if self.__start_wait <= 0: ready_event.wait() ``` **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** [#55](#55), and the matching Java change in [openfeature-java-server#61](launchdarkly/openfeature-java-server#61). Related spec change: [sdk-specs#257](launchdarkly/sdk-specs#257). **Describe the solution you've provided** `main` has since merged [#56](#56), [#57](#57) and [#58](#58); those are merged into this branch, so `start_wait` composes with the wrapper information now passed to `LDClient`, and a failed initialization raises `ProviderNotReadyError` rather than a fatal error. **Describe alternatives you've considered** Waiting on the ready event for `start_wait` seconds inside `initialize` as well: that doubled the effective wait, since the client constructor had already waited the same amount. **Additional context** Testing: `make test` (84 passed) and `make lint`. Tests cover the default matching the SDK default and initialization failing without waiting a second time; the timing assertion fails rather than hanging CI if the double wait comes back. </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] > <sup>[Cursor Bugbot](https://cursor.com/bugbot) is generating a summary for commit 69390f7. 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>
3 tasks
kinyoklion
added a commit
to launchdarkly/openfeature-php-server
that referenced
this pull request
Sep 1, 2026
Maps the LaunchDarkly `WRONG_TYPE` evaluation error kind to the
OpenFeature `TYPE_MISMATCH` error code.
- The kind previously fell through to `GENERAL`, so an application could
not distinguish a flag whose type does not match the requested one from
any other evaluation error.
- Found during the weekly OpenFeature provider audit; `OFP` requirement
3.2.3 prescribes this mapping, and the Java, .NET, Python, Ruby and
JavaScript providers all implement it.
<details>
<summary>Implementation details</summary>
```php
case EvaluationReason::WRONG_TYPE_ERROR:
return new ResolutionError(ErrorCode::TYPE_MISMATCH());
```
**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. The same gap was fixed this week in
[openfeature-python-server#57](launchdarkly/openfeature-python-server#57)
and [js-core#1888](launchdarkly/js-core#1888).
**Describe the solution you've provided**
`ResolutionDetailsConverter::errorKindToCode` gains the missing case.
The LaunchDarkly PHP SDK reports this kind when a flag's value does not
match the requested type, which OpenFeature represents as
`TYPE_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.
</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**
> When the LaunchDarkly SDK returns an evaluation error with kind
`WRONG_TYPE_ERROR`, the OpenFeature provider now surfaces
**`TYPE_MISMATCH`** instead of the generic **`GENERAL`** code.
>
> **`ResolutionDetailsConverter::errorKindToCode`** gains 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 asserts `Reason::ERROR`
plus `ErrorCode::TYPE_MISMATCH()`.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
7fe8ed8. 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
2 participants
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.
The
WRONG_TYPEevaluation error kind is now reported asErrorCode.TYPE_MISMATCHinstead of falling through toGENERAL.Implementation details
Found during the weekly OpenFeature provider audit against
launchdarkly/sdk-specs(OFP).ResolutionDetailsConvertermappedCLIENT_NOT_READY,FLAG_NOT_FOUND,MALFORMED_FLAGandUSER_NOT_SPECIFIED, and every other kind — includingWRONG_TYPE— becameGENERAL, hiding a type mismatch from callers that branch on the error code.EXCEPTION_ERRORintentionally remains mapped toGENERAL.Requirements
Related issues
None.
Describe alternatives you've considered
None; the mapping is prescribed by the spec.
Testing
poetry run pytest(80 passed),poetry run mypy ld_openfeature testsLink to Devin session: https://app.devin.ai/sessions/38a6eaf69fcf41109e136a1d0fe5e899
Requested by: @kinyoklion
Note
Overview
LaunchDarkly evaluation errors with
errorKind: WRONG_TYPEare now converted to OpenFeatureErrorCode.TYPE_MISMATCHinResolutionDetailsConverter, instead of defaulting toGENERAL.A parametrized test covers the new mapping so callers that branch on error codes can detect type mismatches per the OpenFeature provider spec (aligned with other LaunchDarkly providers).
Reviewed by Cursor Bugbot for commit 20eada9. Bugbot is set up for automated code reviews on this repo. Configure here.