openfga_sdk/sync/oauth2.py (1)

82-87: Hard-coding the version string violates DRY

"openfga-sdk (python) 0.9.5" is now duplicated across async & sync clients and a few other modules. Every release requires manual search-and-replace, which is error-prone.

Consider deriving it once, e.g.:

from openfga_sdk import __version__

USER_AGENT = f"openfga-sdk (python) {__version__}"
...
headers = urllib3.response.HTTPHeaderDict(
    {
        "Accept": "application/json",
        "Content-Type": "application/x-www-form-urlencoded",
        "User-Agent": USER_AGENT,
    }
)

Then reuse USER_AGENT everywhere.

openfga_sdk/oauth2.py (1)

82-87: Duplicate hard-coded User-Agent (see sync variant)
Same DRY concern as in sync/oauth2.py. Extract a single constant based on __version__.

test/sync/open_fga_api_test.py (1)

1894-1901: Same brittle User-Agent literal as above

Replicate the fix suggested for the previous block to avoid future maintenance churn.

setup.py (1)

20-22: Avoid hard-coding the version string in multiple files

VERSION here now duplicates the constant in openfga_sdk/__init__.py and appears again in several generated files/tests. This scattering makes future bumps error-prone (one file inevitably drifts). Consider deriving the value from a single source, e.g.

from importlib.metadata import version as _pkg_ver
VERSION = _pkg_ver("openfga-sdk")

or by importing a lightweight version.py module generated once by the build script.
This keeps every location in sync and eliminates manual edits for each release.

example/example1/setup.py (1)

18-18: Specify an upper bound on the dependency range

"openfga-sdk >= 0.9.5" leaves the example project open to unexpected breaking changes from future major releases. Standard practice is to cap at the next incompatible major, e.g.

-REQUIRES = ["openfga-sdk >= 0.9.5"]
+REQUIRES = ["openfga-sdk >= 0.9.5, <1.0.0"]

(Adjust the upper bound to match semantic-versioning guarantees you intend to provide.)

openfga_sdk/configuration.py (1)

537-542: Remove duplicated literal version – fetch it programmatically

"SDK Package Version: 0.9.5" will diverge next time the version is bumped unless every file is edited again. Fetching the installed package version at runtime avoids this:

-import sys
+import sys
+from importlib.metadata import version as _pkg_ver
@@
-            "SDK Package Version: 0.9.5"
+            f"SDK Package Version: {_pkg_ver('openfga-sdk')}"

No circular import occurs because importlib.metadata reads distribution metadata without importing the openfga_sdk package itself.

test/sync/oauth2_test.py (1)

83-88: Derive User-Agent expectation from __version__

Hard-coding "openfga-sdk (python) 0.9.5" couples every test to the release process. Import the constant to keep tests evergreen:

-from openfga_sdk.configuration import Configuration
+from openfga_sdk import __version__ as SDK_VERSION
+from openfga_sdk.configuration import Configuration
@@
-                "User-Agent": "openfga-sdk (python) 0.9.5",
+                "User-Agent": f"openfga-sdk (python) {SDK_VERSION}",

This change removes the need to edit tests on every version bump.

README.md (1)

727-728: Clarify how to pair results with requests a bit further

Good call-out on the ordering guarantee. Consider adding a short example showing how correlation_id can be used to build a dict of {correlation_id: result} so that readers have a concrete pointer.
Something as small as:

results_by_id = {r["correlation_id"]: r for r in response.result}

would make the hint actionable.

openfga_sdk/api_client.py (1)

42-42: Avoid hard-coding the SDK version in the user-agent

Every bump currently requires touching this file (and its sync twin). Feed the value from the single source of truth (openfga_sdk.__version__) instead:

-import openfga_sdk.models
+import openfga_sdk
+import openfga_sdk.models
...
-DEFAULT_USER_AGENT = "openfga-sdk python/0.9.5"
+DEFAULT_USER_AGENT = f"openfga-sdk python/{openfga_sdk.__version__}"

Reduces drift risk and keeps the async/sync clients in sync automatically.

CHANGELOG.md (1)

3-7: Tag names inconsistent with previous releases

Prior entries use the v prefix (v0.9.4, v0.9.3, …) while the new links point to plain 0.9.5. Consider keeping the prefix for consistency and to avoid broken anchors in GitHub-generated release pages.

-### [0.9.5](https://github.com/openfga/python-sdk/compare/v0.9.4...0.9.5) (2025-07-09)
+### [v0.9.5](https://github.com/openfga/python-sdk/compare/v0.9.4...v0.9.5) (2025-07-09)

test/oauth2_test.py (1)

87-88: Derive expected User-Agent from the library version

These assertions repeat a literal "openfga-sdk (python) 0.9.5". If the version changes again the tests will fail for an unrelated reason.

-from urllib3 import response
+import openfga_sdk
+from urllib3 import response
...
-"User-Agent": "openfga-sdk (python) 0.9.5",
+"User-Agent": f"openfga-sdk (python) {openfga_sdk.__version__}",

This keeps the tests green when the version is bumped automatically by the generator. Apply to all occurrences.

Also applies to: 313-315, 368-370, 423-425, 478-480

openfga_sdk/sync/api_client.py (1)

41-41: Avoid hard-coding versioned User-Agent; source it from a single authority

The User-Agent string is now hard-coded with 0.9.5. Each release requires editing multiple files; one miss silently ships an inconsistent UA. Prefer building this from an authoritative value (e.g. openfga_sdk.__version__) and a format helper so every place automatically stays in sync.

-from openfga_sdk import __version__  # add near other imports
-
-DEFAULT_USER_AGENT = "openfga-sdk python/0.9.5"
+from openfga_sdk import __version__  # top-level import
+
+DEFAULT_USER_AGENT = f"openfga-sdk python/{__version__}"

This eliminates duplication across api_client.py, oauth2.py, tests, etc.

test/sync/open_fga_api_test.py (1)

1840-1847: Make UA expectation resilient to future version bumps

"User-Agent": "openfga-sdk python/0.9.5" will break on every release. Pull the value from the code under test:

-                    "User-Agent": "openfga-sdk python/0.9.5",
+                    "User-Agent": openfga_sdk.sync.api_client.DEFAULT_USER_AGENT,

(or import __version__ and format on-the-fly).
This keeps tests green when the version is bumped without touching test fixtures.

test/api/open_fga_api_test.py (2)

1781-1787: Avoid hard-coding SDK version in expected headers

Hard-coding "openfga-sdk python/0.9.5" will break the test on every version bump. Prefer deriving the value from the runtime package to keep the test future-proof.

-                    "User-Agent": "openfga-sdk python/0.9.5",
+                    "User-Agent": f"openfga-sdk python/{openfga_sdk.__version__}",

Repeat the same change wherever the header string is asserted in this file.

---

1835-1841: Duplicate hard-coded version string

Same issue as above—replace the literal 0.9.5 with openfga_sdk.__version__ to avoid perpetual test churn.

-                    "User-Agent": "openfga-sdk python/0.9.5",
+                    "User-Agent": f"openfga-sdk python/{openfga_sdk.__version__}",

openfga_sdk/sync/open_fga_api.py (2)

1600-1600: Docstring collapsed into a single ~2 K-char line – please keep paragraph breaks

The previous multi-line formatting was far more readable and diff-friendly.
Collapsing everything into one monster line makes maintenance (and future reviews) painful and will trip most linters for max-line-length.

Consider reverting to paragraph-based formatting or at least wrapping at ≈100 chars:

-        The Read API will return the tuples for a certain store that match a query filter specified in the body of the request.  The API doesn't guarantee order by any field.  It is different from the `/stores/{store_id}/expand` API ...
+        The Read API will return the tuples for a certain store that match a query
+        filter specified in the body of the request.
+
+        The API doesn't guarantee order by any field.  It differs from
+        `/stores/{store_id}/expand` because it only returns relationship tuples
+        that are *stored* and satisfy the query.
+
+        In the body:
+        1. `tuple_key` is optional. If not specified, all tuples are returned.
+        2. `tuple_key.object` is mandatory when `tuple_key` is present.
+        3. `tuple_key.user` is mandatory when `tuple_key.object` is type-only.

---

1627-1627: Same issue here – long-line docstring in read_with_http_info

Duplicating the giant one-liner in the _with_http_info variant compounds the readability issue. Apply the same paragraph re-flow as suggested above.

openfga_sdk/api/open_fga_api.py (2)

1602-1602: Wrap the monster docstring line for readability & tooling compat

The new sentence is ~1 600 chars long. Sphinx, IDE hovers, and plain pydoc all choke on such unwrapped text, making the docs hard to read and diff.
Break it into short paragraphs and use a bulleted list for points 1-3.

-        The Read API will return the tuples for a certain store that match a query filter specified in the body of the request.  The API doesn't guarantee order by any field.  It is different ...
+        The Read API returns all tuples that match the supplied filter.
+
+        • No ordering of results is guaranteed.  
+        • Unlike `/expand`, only stored relationship tuples are returned.  
+
+        Body rules  
+            1. `tuple_key` is **optional**; when omitted, all tuples are returned.  
+            2. If `tuple_key` is present, `tuple_key.object` is **required** and can
+               be either a fully-qualified object (`type:id`) or a type prefix (`type:`).  
+            3. When a type prefix is used, `tuple_key.user` becomes **required**.  
+
+        ## Examples
+        ...

Keeps the same content, but is friendlier to humans and doc generators.
No functional impact; purely a doc-nit.

---

1629-1629: Duplicate long-line issue in read_with_http_info docstring

Same extremely long line appears here. Apply the same wrapping as suggested
for read to avoid repeated lint / doc-build warnings and improve
maintainability.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro