fix: Report a type mismatch for non-numeric flag values

[kinyoklion]

Numeric flag resolution now accepts only numeric flag values, and converts them to the requested type.

• is_numeric accepted numeric strings, so a flag whose value is "5" was returned as a string from resolveIntegerValue. The OpenFeature client's getIntegerValue(): int then threw a TypeError internally, which it swallows per spec requirement 1.4.9 and reports as error code GENERAL — instead of the TYPE_MISMATCH the provider should have reported.
• Values are now cast, so an integer flag resolves to an int (a float is truncated) and a float flag to a float, rather than passing the raw JSON type through.
• Matches the Python provider, so the same flag value behaves the same way across providers.

Implementation details

} elseif ($flagValueType == FlagValueType::INTEGER && (!is_int($value) && !is_float($value))) {
    return $this->mismatchedTypeDetails($defaultValue);
...
if ($flagValueType == FlagValueType::INTEGER) {
    $value = (int) $value;
} elseif ($flagValueType == FlagValueType::FLOAT) {
    $value = (float) $value;
}

Because the value is converted, the result handed to the details converter is a new EvaluationDetail carrying the converted value with the original variation index and reason. EvaluationDetail::isDefaultValue() is derived from the variation index, which is preserved, so the variant of the resolution details is unchanged.

Found during the weekly OpenFeature provider audit.

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

Related issues

None.

Describe the solution you've provided

The integer and float branches check is_int/is_float instead of is_numeric, and the accepted value is cast to the requested type. Rejected values continue through the existing mismatchedTypeDetails path, so they report TYPE_MISMATCH with the default value.

Describe alternatives you've considered

Keeping is_numeric and casting numeric strings as well: that hides a genuinely mistyped flag instead of reporting it, and disagrees with the other providers.

Additional context

Testing: make check (composer cs-check, composer phpstan, composer phpunit). The existing type-matching data set gains numeric-string and non-integral-float cases and now asserts with assertSame, so the resolved type is checked and not just its loose value.

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
Integer and float flag resolution no longer treats numeric strings as valid: type checks use is_int/is_float instead of is_numeric, so a flag value like "5" now returns the default with TYPE_MISMATCH instead of a string that could surface as a GENERAL error inside the OpenFeature client.

Accepted numeric values are cast to the requested type (int truncates floats; float promotes ints), and the provider passes a new EvaluationDetail with the converted value while preserving variation index and reason.

Tests add numeric-string and float-to-int cases, switch type-matching assertions to assertSame, and cover valueForAll("5") for integer/float resolution errors.

^{Reviewed by Cursor Bugbot for commit 0685543. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 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]

@cursor review

[keelerm84]

It's been a bit since I've looked at this part of the algorithm, but do we typically do this truncation?

[devin-ai-integration]

Yes — truncation is what the other server providers do, which is why I matched it rather than treating a non-integral float as a type mismatch:

• Python _LaunchDarklyProvider__validate_and_cast_value: return int(value) # Float decimals are truncated to int for FlagType.INTEGER.
• Ruby provider.rb integer resolution: evaluation_detail.value.to_i.
• The JS providers have only resolveNumberEvaluation, so the question does not arise there.

Both accept an int or a float and reject bools and numeric strings, which is exactly the shape of the check here.

Worth being explicit that truncation is not what this PR is really about, though: before it, is_numeric let a non-integral float through uncast, so resolveIntegerValue returned 5.5 and the OpenFeature client raised a TypeError that surfaced as GENERAL rather than anything meaningful. So the choice is between truncating like Python and Ruby, or returning TYPE_MISMATCH with the default value. I went with the former for cross-SDK consistency, but if you would rather a 5.5 integer flag be a hard TYPE_MISMATCH here I am happy to switch it — it is a one-line change plus the test, and it would be a deliberate divergence from Python and Ruby.