OpenAI Responses 的 SSE 中断要不要重发？以幂等与恢复策略做一次实战排查

很多人把 SSE 中断当成网络抖动就直接重试，但在包含工具调用、数据库写入或消息下发副作用的场景，这一步最容易踩雷。实践里，我们要先确认当前会话是否已经对外产生过副作用，再决定是否重发；否则“看起来安全”的重放很可能把账单、状态机、消息队列推翻一次。

核心判断是：中断时“是否已提交不可逆操作”。没有副作用就可补流；有副作用则按幂等键继续恢复或做状态回放。

问题边界：SSE 中断不是重试失败，更像“状态一致性”问题

在调用 Responses 的流式接口时，客户端通常会看到三类中断：

1）连接层中断

TCP/网络抖动导致 socket 断开，但服务端仍可能已经继续处理。这个情况下你不知道它是否已经产出完整响应。

2）会话层中断

代理超时、客户端重启、负载均衡切换都可能截断连接。你拿到的是部分 token 或工具事件。

3）业务层中断

你的消费者代码因异常退出导致读取停止，内部却已下发了 function/tool call。重试前先看是否有副作用。

第一步：设计三段式恢复链

把恢复拆成三段能减少误操作：

请求标识：从入口就加上幂等上下文

给每次调用生成 request_trace_id，并在数据库、缓存和应用日志中同时记录。这样重试时先查这个 ID 的最后提交状态，再决定动作。没有这个字段，重试只会放大不确定性。

• 数据库表建议保留 trace_id、stream_state、last_event_id。
• 日志必须保留 tool 阶段事件序号和最终状态。
• 每次发送响应前先写入本地快照（例如 JSON payload 及 checksum）。

副作用分离：先算答案再落执行

把「生成回答」和「执行外部动作」拆开。Streaming 过程中只记录建议动作，真正的副作用放在确认阶段再执行，便于恢复。

1. 先以流式结果构建建议与参数。
2. 在重试前回查 trace_id 的副作用状态。
3. 若未执行成功，按幂等键在执行层重放一次，不要直接重复请求整条流。

状态回放：不是越早重试越好

若 30 秒内频繁断开，可以把重试策略限制为「指数退避 + 最大重试 2 次」。第二次前先拉取服务端状态，确认是否有已完成片段。

第二步：按事件片段做补流与回退

建议的恢复时序如下：

• 先读 trace 表：若状态为已完成或已触发副作用，停止重发，只做补齐展示。
• 若未完成且无副作用记录，按同一幂等键发起短重试。
• 若无法确认，先走“暂停队列 + 人工确认”，别把可疑重放放到生产主链路。

这套策略虽然慢一拍，但在高风险写库/支付/发券场景能显著降低重复执行概率。

代码示意：重试前先查副作用状态

-- 示例为伪代码，突出流程，不可直接复制粘贴用于生产
if trace_state in ["DONE", "SIDE_EFFECT_OK"]:
    return replay_response(trace_id)

if trace_state == "SIDE_EFFECT_FAILED":
    return retry_side_effect(trace_id)

if should_retry_connection() and retry_count 

常见陷阱与坑位排查

陷阱 1：把连接断开当成任务失败

客户端通常在日志里看到 socket close，但服务端已经进入 DONE。此时重发会产生重复回答或重复副作用。先查 trace 状态再判断。

陷阱 2：工具调用与回答耦合

工具执行和文本输出混在同一链路时，断流时很难补齐。把副作用状态独立记录可将“恢复显示内容”和“恢复副作用”分离。

陷阱 3：缺少 last_event_id

不保留最后事件序号，只看到“还没完成”而无法判断遗漏范围。加上事件序号可把重试窗口压缩到最小。

相关问答

断流后能否直接继续消费上一次响应？

不能。只有当你能确认服务端已经落盘最后事件，才可做回放展示；否则从幂等键重新恢复状态。

重试超过两次还不成功怎么办？

停止自动重试，切到故障队列，标记为人工确认。无状态重试会放大问题。

是否必须把每次请求做幂等键？

对外部可见动作的请求必须。纯查询可酌情简化，但有明显副作用的调用建议必开。