Gemini API 错误码排障手册三步跑通重试机制【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook日志里先是 429接着 503一次业务请求卡在 API 调用上。你查网络网络正常查密钥密钥也没问题。这时候排障的第一步其实不是找哪里坏了而是先判断这个 Gemini API 错误码值不值得重试。下面这条分诊 → 启用重试 → 精细控制 → 验证的路径足够让你把服务重新拉起来。 分诊这个错误该不该重试拿到报错先别急着加代码按下表对号入座错误特征典型成因处理方式408 / 500 / 502 / 503 / 504 等瞬态错误网络抖动、服务端临时过载重试通常即可恢复是重试机制的主战场429 Too Many Requests超出模型默认频率限制可以重试但要带渐进延迟持续出现就降低调用速率或申请提额401 / 403 等权限错误密钥失效、权限不足重试没有意义先修凭证⚡ 一键启用内置重试怎么开用google-genaiSDK 时你不用自己写循环。构造客户端时带上HttpRetryOptions就行retry types.HttpRetryOptions( attempts5, initial_delay2.0, max_delay30.0, http_status_codes[408, 429, 500, 502, 503, 504]) client genai.Client(api_keyKEY, http_optionstypes.HttpOptions(retry_optionsretry))收益很直接几乎零额外代码业务逻辑一行不改只在客户端加配置自动扛住瞬态错误SDK 按状态码自己判断是否重发参数可定制attempts定总次数initial_delay/max_delay控制间隔http_status_codes决定哪些码触发重试️ 精细控制用 retry 库自己写需要按错误类型走不同策略时换google.api_core的retry库retry.Retry(predicateis_transient, initial2.0, maximum64.0, multiplier2.0, timeout600) def generate(prompt): ...predicate 筛异常确认是errors.APIError且code落在 {408, 429, 500, 502, 503, 504} 里才重试权限错误直接放过渐进式延迟从 2 秒起步multiplier翻倍maximum封顶不会一直干等timeout 兜底600 秒后停止重试防止死循环占满资源✅ 验证如何确认重试真的生效没验证过的重试代码等于没写。最省事的办法让函数第一次调用故意抛errors.ServerError(503)之后正常调用。如果装饰器接管成功日志会先打出503 Service Unavailable最终结果照常返回。quickstarts/Error_handling.ipynb 里这段就是可复现的样例跑一遍心里就有底了。 调优清单超时与日志等落地建议超时别设太高ReadTimeout/DeadlineExceeded表示调用超过默认 600 秒可在http_options里调大timeout示例里给到 15 分钟但设过高会拖慢报错发现、白白等资源日志留全三要素错误码、时间戳、请求上下文缺一不可否则事后没法回溯把 429 当信号看偶发 429 交给重试兜住连续 429 说明撞上默认频率限制该降速或申请更高配额了重试集合要克制http_status_codes只放瞬态状态码401 这类凭证错误盲目重试只会掩盖真问题错误码不是故障本身它只是服务给你的一份体检单。会分诊、会配置、会验证你的调用链路就不再怕偶发抖动。优秀的错误处理从来不是零错误而是错误发生时系统知道该怎么回应、该留下什么痕迹。【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Gemini API 错误码排障手册：三步跑通重试机制
Gemini API 错误码排障手册三步跑通重试机制【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook日志里先是 429接着 503一次业务请求卡在 API 调用上。你查网络网络正常查密钥密钥也没问题。这时候排障的第一步其实不是找哪里坏了而是先判断这个 Gemini API 错误码值不值得重试。下面这条分诊 → 启用重试 → 精细控制 → 验证的路径足够让你把服务重新拉起来。 分诊这个错误该不该重试拿到报错先别急着加代码按下表对号入座错误特征典型成因处理方式408 / 500 / 502 / 503 / 504 等瞬态错误网络抖动、服务端临时过载重试通常即可恢复是重试机制的主战场429 Too Many Requests超出模型默认频率限制可以重试但要带渐进延迟持续出现就降低调用速率或申请提额401 / 403 等权限错误密钥失效、权限不足重试没有意义先修凭证⚡ 一键启用内置重试怎么开用google-genaiSDK 时你不用自己写循环。构造客户端时带上HttpRetryOptions就行retry types.HttpRetryOptions( attempts5, initial_delay2.0, max_delay30.0, http_status_codes[408, 429, 500, 502, 503, 504]) client genai.Client(api_keyKEY, http_optionstypes.HttpOptions(retry_optionsretry))收益很直接几乎零额外代码业务逻辑一行不改只在客户端加配置自动扛住瞬态错误SDK 按状态码自己判断是否重发参数可定制attempts定总次数initial_delay/max_delay控制间隔http_status_codes决定哪些码触发重试️ 精细控制用 retry 库自己写需要按错误类型走不同策略时换google.api_core的retry库retry.Retry(predicateis_transient, initial2.0, maximum64.0, multiplier2.0, timeout600) def generate(prompt): ...predicate 筛异常确认是errors.APIError且code落在 {408, 429, 500, 502, 503, 504} 里才重试权限错误直接放过渐进式延迟从 2 秒起步multiplier翻倍maximum封顶不会一直干等timeout 兜底600 秒后停止重试防止死循环占满资源✅ 验证如何确认重试真的生效没验证过的重试代码等于没写。最省事的办法让函数第一次调用故意抛errors.ServerError(503)之后正常调用。如果装饰器接管成功日志会先打出503 Service Unavailable最终结果照常返回。quickstarts/Error_handling.ipynb 里这段就是可复现的样例跑一遍心里就有底了。 调优清单超时与日志等落地建议超时别设太高ReadTimeout/DeadlineExceeded表示调用超过默认 600 秒可在http_options里调大timeout示例里给到 15 分钟但设过高会拖慢报错发现、白白等资源日志留全三要素错误码、时间戳、请求上下文缺一不可否则事后没法回溯把 429 当信号看偶发 429 交给重试兜住连续 429 说明撞上默认频率限制该降速或申请更高配额了重试集合要克制http_status_codes只放瞬态状态码401 这类凭证错误盲目重试只会掩盖真问题错误码不是故障本身它只是服务给你的一份体检单。会分诊、会配置、会验证你的调用链路就不再怕偶发抖动。优秀的错误处理从来不是零错误而是错误发生时系统知道该怎么回应、该留下什么痕迹。【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考