[BUG] Heathcheck timeout parameter not parsable

[grechaw]

What is the bug?

the OpenSearch client cannot change the default timeout for health checks.

The cluster endpoint for healthcheck requires a string representing time units:

http "os-morel-1:9200/_cluster/health?timeout=4s"

It fails if you supply an integer or float.

(rayish) √ deus_lex % http "os-morel-1:9200/_cluster/health?timeout=4.2"
HTTP/1.1 400 Bad Request
content-encoding: gzip
content-length: 172
content-type: application/json; charset=UTF-8

{
    "error": {
        "reason": "failed to parse setting [timeout] with value [4.2] as a time value: unit is missing or unrecognized",
        "root_cause": [
            {
                "reason": "failed to parse setting [timeout] with value [4.2] as a time value: unit is missing or unrecognized",
                "type": "illegal_argument_exception"
            }
        ],
        "type": "illegal_argument_exception"
    },
    "status": 400
}

However, the client call requires a numeric value and fails with a time unit string

x = OpenSearch(["http://os-morel-1:9200"])

x.cluster.health(timeout="4s")

ConnectionError: ConnectionError(Timeout value connect was b'4s', but it must be an int, float or None.) caused by: ValueError(Timeout value connect was b'4s', but it must be an int, float or None.)

x.cluster.health(timeout=4)

ConnectionError: ConnectionError(Timeout value connect was 4, but it must be an int, float or None.) caused by: ValueError(Timeout value connect was 4, but it must be an int, float or None.)

How can one reproduce the bug?

Steps to reproduce the behavior.

What is the expected behavior?

As with previous versions of elasticsearch client, I expect "timeout="4s" to work properly

What is your host/environment?

Operating system, version.

Do you have any screenshots?

If applicable, add screenshots to help explain your problem.

Do you have any additional context?

Add any other context about the problem.

[grechaw]

I can see that the 'request_timeout' parameter can be used to get around this issue. I'm not sure if that's recommended practice or if this bug needs fixing.

[grechaw]

This problem emerges from where the client encodes URL parameters as strings, which causes a validation error for the timeout parameter further down the stack.

I will open a PR that resolves the problem. I'll write a test too. I hope you will consider merging it.