ValueError When Handling Retry-After Headers After 429 Too Many Requests Error

[gilron07]

Describe the bug

The issue arises after encountering a 429 Too Many Requests error, which likely returns an incorrect Retry-After header value like 30,120 (representing two retry times or a malformed retry interval). When the retry handler attempts to process this value, it throws an error because it cannot properly parse the value into an integer due to the comma.

<kiota_http.middleware.retry_handler.RetryHandler object at 0x1104f2780>
retry_after = '30,120'

    def _parse_retry_after(self, retry_after):
        """
        Helper to parse Retry-After and get value in seconds.
        """
        try:
>           delay = int(retry_after)
E           ValueError: invalid literal for int() with base 10: '30,120'

Expected behavior

• Server returns proper Retry After value
• Client is able to properly parse value & retry request or if still gets 429, throw an appropriate HTTP exception.

How to reproduce

Steps to Reproduce:

• Trigger a 429 Too Many Requests error by sending multiple simultaneous requests to sites graph endpoint:
  client.sites.get(request_configuration=request)

• Observe that the Retry-After header contains the value "30,120".

• The retry handler fails with the error ValueError: invalid literal for int() with base 10: '30,120'.

SDK Version

1.26.0

Latest version known to work for scenario above?

No response

Known Workarounds

No response

Debug output

Click to expand log

``` self = retry_after = '30,120'

def _parse_retry_after(self, retry_after):
    """
    Helper to parse Retry-After and get value in seconds.
    """
    try:

      delay = int(retry_after)

E ValueError: invalid literal for int() with base 10: '30,120'

../.venv/lib/python3.xx/site-packages/kiota_http/middleware/retry_handler.py:205: ValueError

</details>


### Configuration

_No response_

### Other information

_No response_

[MarcoP9]

Experiencing the exact same problem!

[MarcoP9]

Hello! Is there any update on this? What could be a possible workaround?

[metealp]

same here

[musale]

@gilron07 good catch. This seems to be a casting issue in the http retry middleware.
https://github.com/microsoft/kiota-python/blob/cc340dcc928bbee96a7abb7c18752b892684fc83/packages/http/httpx/kiota_http/middleware/retry_handler.py#L200-L210

Updating this to cater for the returned comma-separated ints and pick the correct one should do the trick. Are you interested in picking this up?