-
Notifications
You must be signed in to change notification settings - Fork 453
Docs fail to document thread-safety of genai client, and it fails irrecoverably on multi-threaded use #211
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
Comments
Hey blocked on the same issue - did you manage to find any sort of workaround? |
@adenalhardan Yes, instead of using the API client library, I ended up directly using the HTTP API endpoint. Using independent HTTP clients (1 per worker thread), then no problems. |
Awesome thank you |
Can you kindly share some general code how you did that? Oh wait - it's in the docs.. Figured it out! thanks https://ai.google.dev/api/rest/v1beta/media/upload?hl=en This works UPDATE - Halfway through the upload, I get this though |
@RukshanJS Here's what I've been using, maybe it'll fix your error
|
This is very helpful thanks a lot!. Do you mind sharing the usage of this client as well. I have a little bit of trouble understanding why we have to use an access token here. Can't we use the Gemini API itself using the key? without using the genai client? |
My current code is,
I call this as, ProblemIt uploads parallel correctly for sometime, and then hangs (doesn't progress after this)
Observations
|
Hey everybody, I think @jpdaigle's original issue is resolved. Aside from The retries may help with a lot of other errors, which seem much less common now. https://gist.github.com/MarkDaoust/dcd65b626bf4683860aa510b79bc225e So I think this bug is fixed. @RukshanJS I've heard other reports of failures with threading specifically for file uploads. How about we continue this in #327 |
Description of the bug:
The Generative Service Client or
GenerativeModel
classes don't document thread safety assumptions, and don't appear to be usable in a multithreaded environment for making concurrent API requests.I'd suggest either:
Behaviour observed: After trying to make concurrent calls to the generative text api, most calls failed with a 60s timeout. The client never recovered (that is, every new call attempt also froze for 60s then ultimately timed out with an error).
Sample error output:
Example snippet:
Actual vs expected behavior:
Actual: all calls fail.
Expected: this case should either work, or client docs should document as non-thread-safe for concurrent usage given how common batch inference scenarios are likely to be.
Any other information you'd like to share?
No response
The text was updated successfully, but these errors were encountered: