OpenFGA SDK doesn't seem to support async_req parameter

[dandua98-cohere]

Checklist

• I have looked into the README and have not found a suitable solution or answer.
• I have looked into the documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have upgraded to the latest version of OpenFGA and the issue still persists.
• I have searched the Slack community and have not found a suitable solution or answer.
• I agree to the terms within the OpenFGA Code of Conduct.

Description

Unless I missed something, it seems the async_req parameter to send requests asynchronously cannot be set from the public APIs. options_to_kwargs doesn't support this parameter, so there's no way to set it without using internal APIs. Is this expected?

Expectation

Description is explanatory.

Reproduction

OpenFGA SDK version

0.9.4

OpenFGA version

1.8

SDK Configuration

Logs

No response

References

No response

[Abishek-Newar]

Hi @dandua98-cohere , I'd like to work on this issue. Would a PR to expose async_req through
options_to_kwargs be welcome?

[emilic]

Thanks for the contribution! However, I don't think we should add async_req support to the SDK.

The async_req parameter is a legacy pattern from OpenAPI Generator that uses threading (ThreadPool) under the hood. The Python SDK already provides a dedicated async client built on asyncio/aiohttp, which is the modern and recommended way to handle async operations in Python.

For example, you can use the async client today:

async with OpenFgaClient(configuration) as fga_client:
    # Single async call
    response = await fga_client.check(request)

    # Concurrent calls
    results = await asyncio.gather(
        fga_client.check(request_1),
        fga_client.check(request_2),
        fga_client.check(request_3),
    )

This gives you everything async_req would, with better performance characteristics and no threading overhead.

If there's a specific use case that the async client doesn't cover, we'd love to hear about it — happy to discuss further.