This PR

I reproduced the behavior reported by @aepfli in #619: requesting a boolean flag through get_integer_details returns the boolean as a successful evaluation, instead of returning the integer default with TYPE_MISMATCH.

The caller gets neither the expected type nor an indication that the flag is misconfigured for that request. The fallback is silently bypassed because Python considers bool a subclass of int, so isinstance(True, int) passes the client's type check.

Reproducing the problem

This example uses the built-in provider; no flag server or credentials are needed. Run it with uv run --frozen python repro.py after saving it as repro.py in the checkout:

import asyncio

from openfeature import api
from openfeature.provider.in_memory_provider import InMemoryFlag, InMemoryProvider


async def main():
    api.set_provider_and_wait(
        InMemoryProvider({"flag": InMemoryFlag("on", {"on": True})})
    )
    try:
        client = api.get_client()
        for mode, details in (
            ("sync", client.get_integer_details("flag", 1)),
            ("async", await client.get_integer_details_async("flag", 1)),
        ):
            error = details.error_code.value if details.error_code else None
            print(
                f"{mode}: {details.value!r} ({type(details.value).__name__}), "
                f"{details.reason.value}, {error}"
            )
    finally:
        api.shutdown()


asyncio.run(main())

On the base commit, 371aca1:

sync: True (bool), STATIC, None
async: True (bool), STATIC, None

With this patch, the same example returns the supplied default and reports the mismatch:

sync: 1 (int), ERROR, TYPE_MISMATCH
async: 1 (int), ERROR, TYPE_MISMATCH

I also checked False with a default of 0. The type matters here: a test that only checks equality would pass even before the fix, since True == 1 and False == 0.

Why there are two changes

The shared type check now excludes booleans when the requested type is INTEGER. I kept isinstance for everything else so this doesn't also reject valid integer subclasses or change how other flag types are handled.

That change alone wasn't enough for the async API. While checking it, I found that the async type-mismatch branch still constructed its result with resolution.value. It reported an error, but returned the rejected value anyway. The second change uses default_value in that branch, matching the sync behavior.

This also corrects the async fallback for other client-detected type mismatches, which is why the tests cover more than bool-to-int. It doesn't change provider implementations or introduce type coercion. Boolean flags and objects containing booleans continue to work as before.

Related Issues

Fixes #619. Thanks @aepfli for the reproduction and the conformance test that caught this.

How to test

The added tests exercise both value and details getters through the real InMemoryProvider. They check the exact return type as well as the value, error details and hook behavior: a mismatch must run the error hook, skip the after hook, and give the finally hook the fallback value. There are also passing cases for valid flag values and an integer subclass, to check that the stricter bool handling doesn't affect them.

To run just these tests:

uv run --frozen pytest tests/test_client.py -q \
  -k 'client_returns_default_on_type_mismatch or client_preserves_matching_flag_types or typecheck_flag_value_accepts_integer_subclasses'

I ran the same 39 cases against the unmodified base and this patch. Before the fix, 11 failed and 28 passed: the failures were the two sync bool-to-int cases and the nine async mismatch cases. After the fix, all 39 passed.

The full suite passed on Python 3.10 through 3.14, with 211 tests on each version. The repository's Gherkin suite also passed on each version: 21 scenarios / 84 steps, using its pinned spec and in-memory provider. Ruff, mypy, the remaining pre-commit hooks, and the wheel/sdist build passed locally as well.

UV_FROZEN=1 uv run --frozen poe test-all
UV_FROZEN=1 uv run --frozen poe e2e
UV_FROZEN=1 uv run --frozen prek run --all-files --show-diff-on-failure
uv build --no-sources

Notes

For a check independent of the tests added here, I ran the in-memory self-test from python-sdk-contrib#409, at d6de5dc, against both SDK versions. The case marked as a known failure for #619 becomes XPASS(strict) with this patch. Running that unchanged test file with --runxfail, so the assertions run normally, gives 24 passed and 5 skipped. The skips are unsupported provider capabilities; the strict marker will need updating when that suite adopts the fixed SDK.

All results above are local macOS runs. I haven't tested against live flagd/OFREP servers, and these results don't replace hosted CI.