Skip to content

Comments

fix: ensure requestTimeout and maxRetries are integers#394

Open
tgarciaalv wants to merge 3 commits intookta:masterfrom
tgarciaalv:patch-1
Open

fix: ensure requestTimeout and maxRetries are integers#394
tgarciaalv wants to merge 3 commits intookta:masterfrom
tgarciaalv:patch-1

Conversation

@tgarciaalv
Copy link

This is failing when environment variables are used for configuration. Env vars are strings but are never converted to int before using them in arithmetic operations.

My configuration:

              "OKTA_CLIENT_CONNECTIONTIMEOUT": "30",
               "OKTA_CLIENT_ORGURL": "https://dev-89428916.okta.com",
               "OKTA_CLIENT_AUTHORIZATIONMODE": "PrivateKey",
               "OKTA_CLIENT_CLIENTID": "${env:OKTA_CLIENT_CLIENTID}",
               "OKTA_CLIENT_SCOPES": "okta.users.read,okta.groups.read",
               "OKTA_CLIENT_PRIVATEKEY": "${env:OKTA_CLIENT_PRIVATEKEY}",
               "OKTA_CLIENT_REQUESTTIMEOUT": "0",
               "OKTA_CLIENT_RATELIMIT_MAXRETRIES": "4",
               "OKTA_CLIENT_LOGGING_ENABLED": "true",
               "OKTA_CLIENT_LOGGING_LEVEL": "INFO",

My error:

        # Raise Value Error if numerical inputs are invalid (< 0)
        self._request_timeout = config["client"].get('requestTimeout', 0)
>       if self._request_timeout < 0:
E       TypeError: '<' not supported between instances of 'str' and 'int'

/opt/homebrew/lib/python3.11/site-packages/okta/request_executor.py:35: TypeError

The os.environ dictionary in Python expects its values to be strings.

@bryanapellanes-okta
Copy link
Contributor

@tgarciaalv I apologize for the delayed response and thank you for your submission. To ensure integrity, please provide a unit test that fails prior to your proposed change and passes with your change in place.

We appreciate your engagement and thanks for using Okta!

@BinoyOza-okta
Copy link
Contributor

Hi @tgarciaalv,
Thanks for your submission. As per the last comment, please update the PR with the unit tests and resolve the merge conflicts.

This is failing when environment variables are used for configuration. Env vars are strings but are never converted to int before using them in arithmetic operations.

        # Raise Value Error if numerical inputs are invalid (< 0)
        self._request_timeout = config["client"].get('requestTimeout', 0)
>       if self._request_timeout < 0:
E       TypeError: '<' not supported between instances of 'str' and 'int'

/opt/homebrew/lib/python3.11/site-packages/okta/request_executor.py:35: TypeError
@tgarciaalv
Copy link
Author

tgarciaalv commented Feb 18, 2026

Hi @bryanapellanes-okta @BinoyOza-okta,

Thanks for the feedback. I've rebased onto master, resolved the merge conflicts, and added unit tests. I also fixed the CI failure on Python 3.13.

Changes

1. int() casts for env var config values (okta/request_executor.py)

  • requestTimeout and maxRetries are now cast to int before arithmetic comparison
  • Without this, env vars (always strings) cause TypeError: '<' not supported between instances of 'str' and 'int'

2. Unit tests (tests/unit/test_request_executor.py)

  • 8 tests covering: string values, int values, zero strings, and negative string validation
  • All fail before the fix (TypeError), all pass after

3. Python 3.13 CI fix (requirements.txt, setup.py, okta/config/config_setter.py)

  • Replaced flatdict==4.0.1 (abandoned, last release 2020) with flatdict2==4.0.4 (maintained fork, identical API)
  • flatdict fails to build on Python 3.13 because it uses pkg_resources (removed from stdlib)
  • This was a pre-existing issue on master unrelated to my original fix

How to verify

pytest tests/unit/test_request_executor.py::TestRequestExecutorStringConfig -v

Let me know if anything else is needed.

flatdict==4.0.1 (last release 2020) uses pkg_resources in its setup.py,
which was removed from Python 3.13 stdlib. flatdict2 is a maintained
fork with identical API and pre-built wheels.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants