Otherwise when doing calls to toolforge, the fastapi server blocks and prevents serving any new requests.
Luckily, we can now generate it from the openapi def :)
Otherwise when doing calls to toolforge, the fastapi server blocks and prevents serving any new requests.
Luckily, we can now generate it from the openapi def :)
dcaro opened https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-weld/-/merge_requests/65
api_client: add the async version of the API client
dcaro opened https://gitlab.wikimedia.org/repos/cloud/toolforge/components-api/-/merge_requests/36
use async toolforge cli
dcaro updated https://gitlab.wikimedia.org/repos/cloud/toolforge/components-api/-/merge_requests/36
use async toolforge cli
This might not actually be needed :)
Reading https://fastapi.tiangolo.com/async/ and doing some tests to verify
Yep, we don't need to use async libraries to avoid the api from getting blocked, it will handle non-async code in a threadpool automatically and "do the right thing",
Dropping this task and the MRs :)
dcaro closed https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-weld/-/merge_requests/65
api_client: add the async version of the API client
dcaro closed https://gitlab.wikimedia.org/repos/cloud/toolforge/components-api/-/merge_requests/36
use async toolforge cli