Skip to content

Conversation

@SgtMarmite
Copy link

@SgtMarmite SgtMarmite commented May 25, 2023

Things to discuss:

  • naming of retry_status_codes x status_forcelist
  • retries x max_retries
  • tests coverage
  • any missing functions?
  • are more examples needed?
  • fix httpx version or not?
  • currently, the backoff time is calculated like backoff = self.backoff_factor ** retry_attempt and I do not know if that is sufficient.

I do not know if I need to change anything in .github/workflows.

TODO:

@SgtMarmite
Copy link
Author

Currently all requests urls are logged into console. This is not intended functionality and I will have to find a way to disable that.


response = None

for retry_attempt in range(self.retries + 1):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this is not needed and the retry can be handled by the same logic as in the normal client using httpx.Retry and by starting the client(session) with retry parameter see example here


jobs = generate_jobs(1000)

results = await client.process_multiple(jobs)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a way to achieve this without having the main_async function async? E.g. something like this My idea was to have a function, that would run and wait for multiple jobs and just returned all the results (with the disadvantage of having to store all results in memory). Then I would just call something like results = client.run_multiple_sync() in my sync function. Is that possible?

Also I somehow dislike the name process_multiple what does it do? It actually sends multiple requests (not jobs) and returns list of result futures right? The request is basically the parameters of _request_raw http.py equivalent. I think it should be named something like run_multiple_requests(). Also I can imagine having equivalent for each method, e.g. post_multiple

@soustruh
Copy link
Contributor

soustruh commented Oct 1, 2025

Closing this PR in favor of #9

@soustruh soustruh closed this Oct 1, 2025
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.

4 participants