[Bug] v5.0.0 生图反复触发 15s 端点超时，最终上游 200 后返回 502 No images generated #3756

问题描述

使用 POST /v1/images/generations 调用 gemini-3.1-flash-image 生成单张 4K 图片，等待约 290.801 秒后返回：

HTTP 502
No images generated

对齐容器日志后发现，这个 502 由 Manager 生成：最后一次 Sandbox 上游返回 HTTP 200，紧接着 Manager 报没有生成图片。在此之前还经历了明确的 429 配额耗尽和多次每端点 15 秒的响应头超时。

想请维护者核实两点：

1. v5.0.0 将非流式 generateContent 生图请求与轻量请求共用短响应头看门狗，是否可能过早中断正常但耗时较长的生图？
2. 上游 200 却没有可提取图片时，目前只返回通用 502，缺少 finishReason、promptFeedback、候选数量/类型等信息，无法判断是未生成、拒绝生成，还是格式未正确处理。

尚未在相同账号、提示词和网络条件下做 4.9.8/5.0.0 对照测试，因此这里报告的是已观察到的行为和回归嫌疑，不把所有失败直接归因于新版。

环境

• Manager：5.0.0，/health 确认。
• 部署：fnOS NAS / Linux，Docker，lbjlaq/antigravity-manager:latest。
• 镜像 ID：sha256:a841e72ecfdc3189701fac64513072e8735c18412f80ea8e4ccabaf2e5808a87。
• 上游通过 HTTP 代理访问；存在网络或服务端抖动的可能。
• 账号池：6 个账号，启用轮换。
• 配置：request_timeout=360；image_scheduler.per_account_concurrency=4。
• 日志存储模式：simple；debug_logging.enabled=false。

请求参数

实际容器日志确认：

model="gemini-3.1-flash-image"
image_count=0
n=1
size="3312x2480"
quality="high"
style="vivid"

此版本将 quality=high 映射为 imageSize=4K。未提供参考图。原始提示词和凭据不公开。

复现入口是向上述接口发送单张、quality=high 的生图请求，观察端点响应头超时、重试和最终图片提取结果。问题具有间歇性；以上参数不构成保证复现的最小用例。

已观察到的时间线

2026-10-26，以下表格为 UTC+8；流量记录时间为 19:28:33，对应返回阶段，实际请求约在 19:23:42 开始。

关键日志节选（原始 UTC；账号和 UUID 已隐去）：

2026-10-26T11:23:42.440665181+00:00 INFO [Images] Received generation request model="gemini-3.1-flash-image" image_count=0 n=1 size="3312x2480" quality="high" style="vivid"
2026-10-26T11:23:42.928328460+00:00 INFO [image_generation] Retry with fixed delay: status=429, attempt=1/12, delay=30000ms

2026-10-26T11:24:27.941600223+00:00 WARN Upstream candidate endpoint timed out, fast falling back to next endpoint err_msg=HTTP request timed out after 15s waiting for response headers at https://daily-cloudcode-pa.googleapis.com/v1internal (method=generateContent, body_len=7584, total_elapsed=15.0s)
2026-10-26T11:24:42.943278916+00:00 WARN Terminal upstream endpoint timed out err_msg=HTTP request timed out after 15s waiting for response headers at https://daily-cloudcode-pa.sandbox.googleapis.com/v1internal (method=generateContent, body_len=7584, total_elapsed=30.0s)

2026-10-26T11:27:09.859094354+00:00 INFO [image_generation] Retry with fixed delay: status=429, attempt=8/12, delay=30000ms
2026-10-26T11:28:33.240323611+00:00 INFO Upstream fallback succeeded | Endpoint: https://daily-cloudcode-pa.sandbox.googleapis.com/v1internal | Status: 200 OK | Next endpoints available: 0
2026-10-26T11:28:33.240752392+00:00 ERROR [Images] All 1 requests failed. Errors: No images generated

流量数据库记录：status=502、duration=290801、error="No images generated"。未保存转出请求；响应正文只有这句错误，原始上游 200 的候选/拒绝信息也没有保留。因此不能确认最后一次 200 的具体内容，更不能据此断言是安全拦截或额度耗尽造成空图。

另外，simple 模式下这条请求正文只剩 model；实际尺寸、质量等已由接收日志确认，不能将简化记录理解为客户端真的没有发送 prompt。

4.9.8 与 5.0.0 源码对比

生图响应头超时策略发生变化

• 4.9.8 upstream/client.rs：短看门狗仅在 has_next 时生效；最后端点走 send_future.await，不受这一层短看门狗约束。
• 5.0.0 upstream/client.rs：calculate_total_upstream_budget_secs / calculate_endpoint_watchdog_secs 对非流式请求按 body 长度计算短预算；约 7.6 KB 的请求落入首端点 15 秒、备用端点 15 秒的分支，最后端点也被包装进 tokio::time::timeout。

这里按请求字节数区分耗时，可能无法反映 4K 生图的计算时长。是否需要将 requestType=image_gen 或图片模型纳入独立超时策略？

空图 502 是原有逻辑，不是已证实的新回归

• 4.9.8 空图分支
• 5.0.0 空图分支

对比后，这段结果收集逻辑相同。成功解析上游 JSON 后，即使没有有效图片，内部任务仍返回 Ok；外层只读取首个候选的 inlineData.data，提取结果为空且没有任务错误时，最终统一返回 No images generated。这会掩盖真实原因。

期望行为

• 为慢生图设置合理、可配置的响应头等待预算，避免直接套用轻量控制接口的短超时；仍保留有界等待，避免无限挂起。
• 区分“HTTP 200”和“成功提取图片”，为无图结果给出明确错误分类及有界重试策略。
• 对无图响应保留经过脱敏的诊断摘要，例如 finishReason、promptFeedback、候选数、part 类型和图片数据是否为空，避免记录完整图片或隐私提示词。
• 保留先前端点超时/429的摘要，方便解释最终 502 与总耗时。

本次仅进行了日志读取和源码对比，没有修改服务配置、重启容器或回退版本。