[Feature Request]: Support automatic retry on failure for Gemini overload

[OnlineMo]

Problem Description

When using the Gemini API, requests often fail—especially with overload errors during peak usage times. This forces manual retries, which disrupts workflow and lowers productivity.

Proposed Solution

Implement an automatic retry mechanism that:

• Retries non-fatal errors such as overload, network timeouts, or temporary connection failures
• Allows configuration of retry count and interval
• Supports optional exponential backoff to reduce service impact
• Logs clear error messages if retries are exhausted, to help with troubleshooting

Alternatives Considered

Manual retrying of failed tasks, which is inefficient and prone to interrupting ongoing processes.

Additional Context

The Gemini API is especially prone to overload during high-traffic periods. An automated retry feature would greatly improve stability and user experience.

---

Chinese

Problem Description

在使用 Gemini API 过程中，经常会出现请求失败的情况，尤其是 overload 错误。这导致当前任务必须手动重试，严重影响了使用体验和任务的连续性。

Solution Description

建议在程序中增加“失败自动重试”机制：

• 针对 overload、网络超时、临时连接错误等非致命性错误，自动进行多次重试
• 支持可配置的重试次数与间隔
• 可选的指数退避（exponential backoff）策略，以减少对服务的冲击
• 在重试仍失败时，输出清晰的错误日志方便用户排查

Alternatives Considered

手动重试任务，但效率低下且容易中断当前工作流。

Additional Context

Gemini API 在高峰期时尤其容易 overload，目前没有自动化的应对方案。该功能可显著提高使用稳定性和体验。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Problem Description

When using the Gemini API, request failures often occur, especially the overload error. This causes the current task to have to be retryed manually, seriously affecting the user experience and task continuity.

Solution Description

It is recommended to add the "Failed Automatic Retry" mechanism to the program:

• Automatically retry multiple times for non-fatal errors such as overload, network timeout, temporary connection error, etc.
• Supports configurable retry times and intervals
• Optional exponential backoff strategy to reduce impact on the service
• When retry still fails, the output of clear error logs is convenient for user troubleshooting

Alternatives Considered

Retry the task manually, but is inefficient and easily interrupts the current workflow.

Additional Context

Gemini API is especially easy to overload during peak periods, and there is currently no automated response. This feature significantly improves usage stability and experience.

[Amery2010]

I'll consider this, but there may be some implementation issues.

The project currently has a default three-try retry mechanism, but Gemini API exceptions often can't be resolved within a short retry window.

Regarding error logging, I'll consider adding this feature to more clearly inform users of the cause of the error.

Currently, it's recommended to use open-source projects like gemini-balance or new-api as API intermediaries. These projects offer comprehensive solutions to Gemini issues.

[OnlineMo]

English
When using Gemini-balance, there are occasional cases where the response is completely empty.
It’s recommended to add an optional auto-retry feature when the following non-fatal errors occur:

• Empty response (no output)
• Overload
• Network timeout
• Temporary connection error

The auto-retry mechanism could:

• Allow configurable retry count and interval
• Support optional exponential backoff strategy to reduce service impact
• Output clear error logs when retries are exhausted, to help troubleshooting

This improvement would enhance stability and user experience, reducing the need for manual retries.

---

中文
在使用 Gemini-balance 时，偶尔会出现“回答为空”的情况。
建议增加一个可选项，当出现以下非致命性错误时自动进行重试：

• 回答为空（无输出）
• overload（服务过载）
• 网络超时
• 临时连接错误

自动重试机制可包括：

• 支持配置重试次数与间隔
• 可选指数退避（exponential backoff）策略，以减少对服务的冲击
• 重试失败后输出清晰的错误日志，方便排查

这样可以显著提升稳定性和使用体验，减少人工干预。