问题概述
生产用户任务中，lark-cli sheets +table-put --sheets ... --styles ... 写入 588 行数据 + 1 行表头、10 列，共 5,890 个单元格，单个 set_cell_range 请求约 1.36 MB，约 62.4 秒后返回 HTTP 502 Bad Gateway。
后续改成 75 行分批后，部分批次仍出现 502（包括 75 行和尾批 63 行）；因此不能简单认定“超过某个行数必然失败”或“拆批即可解决”。原任务在多次重试和调整批次后总耗时约 18.5 分钟。
这是已观测到的生产故障，根因尚未确认。 希望协助定位超时/502 所在层，以及明确结果不确定时的安全恢复方式；暂不将根因归于 CLI、网关或 Sheets 服务中的任何一方。
环境与生产证据
- 生产 CLI：1.0.92，通过失败请求的
User-Agent: lark-cli/1.0.92 确认。
- 身份：
user。
- 生产路径经过 Agent 沙箱代理。
- 发生时间：2026-09-18 02:59:16–03:00:19（UTC+8）。
- 失败请求 LogID：
021789671556855fdbddc530010014e120c3c0ec4000032338be2。
- 请求：
POST /open-apis/sheet_ai/v2/spreadsheets/<redacted>/tools/invoke_write。
- 操作：
set_cell_range，范围 A1:J589。
Content-Length: 1361278；代理侧记录耗时约 62.425 秒，返回 HTTP 502；代理授权判定为允许。- CLI 退出码 4，错误字段为
type=network、subtype=server_error、code=502、retryable=true。
脱敏错误摘要（message 中省略了 HTML 响应体，仅保留其标题）：
{
"ok": false,
"identity": "user",
"error": {
"type": "network",
"subtype": "server_error",
"code": 502,
"message": "table-put failed on <redacted>: writing sheet \"<redacted>\" failed: writing rows 1-589: HTTP 502: ...502 Bad Gateway...",
"hint": "no sheets were written; fix the cause and retry",
"log_id": "021789671556855fdbddc530010014e120c3c0ec4000032338be2",
"retryable": true
}
}这些日志能确认经过代理后收到了 502，不能确认是哪个网关/服务生成了 502，也不能仅凭 CLI 的 hint 确认服务端完全没有落表。
希望维护者协助确认
- 能否用上述时间和请求 LogID 确认约 62 秒的 502 来自哪一层？
invoke_write 是否存在相关超时/负载限制，客户端应如何识别？
- 对 HTTP 502 / 超时这种写入结果不确定的情况，
no sheets were written 的依据是什么？是否可以区分“确认没有生效”和“结果未知”，给出回读后仅补写未完成范围的指导？是否有可查询的请求结果标识或幂等机制？
- 能否提供可配置的单批行数/单元格数/序列化字节预算，或在失败时给出有界的缩批恢复方案，同时避免重写已成功部分？这里不预设固定 75 行一定更合理。
lark-sheets 的“一步带样式”指导能否补充大数据/多格式操作场景的边界，并与 CLI 的实际拆批和恢复行为一致？
关联：#2720（失败时的原子性及落表结果契约）、#2140（Skill 与 CLI 指引一致性）。本 issue 重点是生产 invoke_write 的 502 及恢复语义，不将其它已修复的样式问题视为同一根因。
问题概述
生产用户任务中，
lark-cli sheets +table-put --sheets ... --styles ...写入 588 行数据 + 1 行表头、10 列，共 5,890 个单元格，单个set_cell_range请求约 1.36 MB，约 62.4 秒后返回 HTTP 502 Bad Gateway。后续改成 75 行分批后，部分批次仍出现 502（包括 75 行和尾批 63 行）；因此不能简单认定“超过某个行数必然失败”或“拆批即可解决”。原任务在多次重试和调整批次后总耗时约 18.5 分钟。
这是已观测到的生产故障，根因尚未确认。 希望协助定位超时/502 所在层，以及明确结果不确定时的安全恢复方式；暂不将根因归于 CLI、网关或 Sheets 服务中的任何一方。
环境与生产证据
User-Agent: lark-cli/1.0.92确认。user。021789671556855fdbddc530010014e120c3c0ec4000032338be2。POST /open-apis/sheet_ai/v2/spreadsheets/<redacted>/tools/invoke_write。set_cell_range，范围A1:J589。Content-Length: 1361278；代理侧记录耗时约 62.425 秒，返回 HTTP 502；代理授权判定为允许。type=network、subtype=server_error、code=502、retryable=true。脱敏错误摘要（message 中省略了 HTML 响应体，仅保留其标题）：
{ "ok": false, "identity": "user", "error": { "type": "network", "subtype": "server_error", "code": 502, "message": "table-put failed on <redacted>: writing sheet \"<redacted>\" failed: writing rows 1-589: HTTP 502: ...502 Bad Gateway...", "hint": "no sheets were written; fix the cause and retry", "log_id": "021789671556855fdbddc530010014e120c3c0ec4000032338be2", "retryable": true } }这些日志能确认经过代理后收到了 502，不能确认是哪个网关/服务生成了 502，也不能仅凭 CLI 的 hint 确认服务端完全没有落表。
希望维护者协助确认
invoke_write是否存在相关超时/负载限制，客户端应如何识别？no sheets were written的依据是什么？是否可以区分“确认没有生效”和“结果未知”，给出回读后仅补写未完成范围的指导？是否有可查询的请求结果标识或幂等机制？lark-sheets的“一步带样式”指导能否补充大数据/多格式操作场景的边界，并与 CLI 的实际拆批和恢复行为一致？关联：#2720（失败时的原子性及落表结果契约）、#2140（Skill 与 CLI 指引一致性）。本 issue 重点是生产
invoke_write的 502 及恢复语义，不将其它已修复的样式问题视为同一根因。