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

Asyncronous Client #76

Merged
merged 15 commits into from
Apr 12, 2024
Merged

Asyncronous Client #76

merged 15 commits into from
Apr 12, 2024

Conversation

meksor
Copy link
Contributor

@meksor meksor commented Mar 26, 2024

Makes some of the client code asynchronous. This enables the concurrent sending of requests for enumerations.
Asynchronicity is /not/ exposed to the user via async functions.
Adds some settings variables to control client behaviour, like retries, how long to wait before retrying and when the new ApiEncumbered exception is thrown.

client_max_concurrent_requests: int = Field(2, lt=4)
client_max_request_retries: int = Field(3)
client_backoff_factor: int = Field(5)
client_timeout: int = Field(30)

Uses asyncio.Semaphore to control the maximum concurrency.

@meksor meksor marked this pull request as draft March 26, 2024 09:38
@meksor meksor marked this pull request as ready for review April 11, 2024 13:31
Copy link
Member

@glatterf42 glatterf42 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you still add a test for the new functions, maybe especially if the new error is raised correctly?

Other than that, looks good to me :)

pyproject.toml Outdated Show resolved Hide resolved
@meksor
Copy link
Contributor Author

meksor commented Apr 12, 2024

I can't really add tests for that, no. There is in general 2 ways the new exception is triggered and they are both dependant on the webserver configuration and how beefy the setup is.
For example, ixmp4 would never send the response code 429 because it is not able to tell if the entire system is overloaded. Only the webserver/proxy (in our case nginx) in front of ixmp4 or the process manager/ orchestration thingy (in our case docker/kubernetes) could know this and react to it by returning 429. Also tracking IP's and rate limiting by IP is something best done in the webserver.
I can imagine writing system tests that include ixmp4 and check if the exception is thrown under certain circumstances, but there is some way to go until then.

Copy link
Member

@glatterf42 glatterf42 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, lgtm then :)

@meksor meksor merged commit 41eea83 into main Apr 12, 2024
7 checks passed
@meksor meksor deleted the improvement/async-client branch April 12, 2024 11:56
@meksor meksor mentioned this pull request May 2, 2024
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.

2 participants