Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fine-grained timeout for httpx #452

Open
joein opened this issue Jan 20, 2024 · 2 comments
Open

Fine-grained timeout for httpx #452

joein opened this issue Jan 20, 2024 · 2 comments

Comments

@joein
Copy link
Member

joein commented Jan 20, 2024

Timeout param type has been changed in QdrantClient from Optional[float] to Optional[int] to be on par with other timeouts.

Some users used to pass not supported httpx.Timeout, which allowed more fine-grained control over timeouts.

While I don't consider it to be a bad idea, it is doubtful for me whether we would like to explicitly add support for httpx.Timeout, or not, since it is not applicable to gRPC.

What can be painless at the moment is to ease the condition which prevents using types other than those allowed by math.ceil

While the decision has not been made yet, using types other than allowed by the interface is on the users risk

Hello @joein,
I feel this PR introduces a regression. We used to provide an httpx.Timeout object to our QdrantClient, which, although it wasn't compliant with the typings, allowed fine-grained timeout management between connect, read and write timeouts. Maybe it would be more appropriate to change the parameter type to Union[float, httpx.Timeout, None] and handle the types with dedicated logic in the constructor ?

Originally posted by @LouisAuneau in #443 (comment)

@joein
Copy link
Member Author

joein commented Jan 31, 2024

@LouisAuneau unfortunately, we can't just ease the condition due to mypy complaints, we would need to do another workaround, but it won't be available in 1.7.2 :(

we will come back to it later

@LouisAuneau
Copy link

Thanks for your feedback @joein. For now we set an upper bound to 1.7.0 to solve the problem.

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

No branches or pull requests

2 participants