fix: retry on Gemini API errors and handle equip error while a window is open - #794
Conversation
Add error handling when equipping items while a window is open. If it still errors, then gracefully fail and log failure.
| const MAX_RETRIES = 5; | ||
| const RETRY_DELAY = 5000; | ||
|
|
||
| for (let attempt = 0; attempt < MAX_RETRIES; attempt++) { |
There was a problem hiding this comment.
IIRC no other providers have a built-in retry system. Does this need to be implemented specifically for Gemini? Or should there be a separate retry system at another layer for all providers?
There was a problem hiding this comment.
I'm sorry, but I only tested this with Gemini, and thus I can't really tell you whether or not this should be at another layer for all providers.
There was a problem hiding this comment.
Hello, just following up on this, but does this answer your question?
There was a problem hiding this comment.
mm yea but i feel like we probably don't need a retry system or we could make it for example if an error is 404/401/403/400 then don't retry, only retry on 529/502/server errors
and it probably best to have retry system across all providers
2 participants
This PR contains two small bug fixes:
1. Gemini API retry logic (src/models/gemini.js)
The Gemini API occasionally returns 503 (service unavailable), 429 (rate limited), or an empty response, especially under load with multiple agents running. Previously this caused the agent to crash or silently fail. This adds a retry loop of up to 5 attempts with a 5 second delay between each. The number 5 is rather arbitrary, but I found that the agents usually never exceeded even 3 calls, so 5 calls was just a number I thought was safe, but not ridiculously large as to cause the agent to wait forever.
Edit: I am running with Gemini 2.5 Flash-Lite (for context)
2. Equip crash with open window (src/agent/library/skills.js)
Calling bot.equip(item, 'hand') throws when the bot has a container window open (e.g. a chest). This closes any open window before equipping to hand, and wraps the call in a try/ catch so the agent can recover gracefully instead of crashing. I stumbled into this bug while just having a single agent attempting to progress in a world. This didn't happen often, but it did happen. The most common case I found was with a crafting table and attempting to equip a tool.
P.S. My apologies if this isn't super well written. This is my first PR and doing something like this to be honest! I would love any feedback!! :D