请求恢复：退避、传输回退与增量复用
区分重试次数、等待时间、连接基线和已经发生的工具副作用。
学完你能做到
- 能解释次数预算与服务端等待期
- 能判断增量请求是否兼容旧基线
- 能区分请求恢复和工具
本课目录 · 4 节
1. 先判断是否可重试
handle_response_stream_error 先询问 err.retry_delay；不可重试错误直接返回。的 ContentFilter 还先把相关指导写入历史。常规重试增加 retries，等待 的 deadline 或本地 delay；服务端建议改变时机，不自动增加次数。
错误与请求类型 ↗codex-rs/core/src/responses_retry.rs:57–98
预算及截止时间 ↗codex-rs/core/src/responses_retry.rs:140–177
通知 UI 已花掉的时间，必须计入原截止时间。现有测试专门模拟通知延迟，检查恢复时间仍对应服务器最早给出的 deadline。发布构建可能隐藏第一次 重试提示，所以界面安静不能证明没有重试。
通知延迟测试 ↗codex-rs/core/src/responses_retry_tests.rs:53–99
2. 特定连接失败有另一份计数
启用 UnboundedConnectionRetries，且是普通、ConnectionFailed、非内部、provider 非 Amazon Bedrock 时，使用 connection_retries。等待从 5 秒开始倍增，最多 60 秒，不消耗同一份普通 retries。这个分支不能推广为所有错误无限重试。
连接恢复条件 ↗codex-rs/core/src/responses_retry.rs:93–118
3. 耗尽预算后，按条件切换传输
普通预算耗尽且允许 fallback 时，先调用 try_switch_fallback_transport 切换并重置 状态；若切换成功，再等到原 deadline，发出 → 警告，清零普通 retries，允许后续请求。切换本身不能让重发提前越过服务端期限。无法继续时保存带 turn_id 的 ExhaustedResponseRetry 并返回错误，避免把上一的建议误用到当前。
回退与等待 ↗codex-rs/core/src/responses_retry.rs:120–139
连接状态清理 ↗codex-rs/core/src/client.rs:2380–2391
终止建议属于具体回合 ↗codex-rs/core/src/responses_retry.rs:169–176
4. 增量复用要求整个基线成立
get_incremental_items 要求非 input 属性不变，当前 input 延续旧请求 input 与服务端 output items。输入缩短、前缀不同或请求属性变化时返回非增量原因。它验证的是完整基线，不是只比较最后增加的一段文本。或设置变化可能使旧基线不再成立。
增量基线校验 ↗codex-rs/core/src/client.rs:1468–1502
此处是 Responses 请求恢复，不是业务工具的通用重试器。工具已经写文件或发送请求后断线，是否发生副作用要看执行记录和目标系统。重试请求不会自动赋予工具。设计类似系统时，应分别保存“工具未执行”“已执行但结果未知”“结果已入历史”等状态；幂等键与可查询操作状态属于额外的工具设计。
沿着源码读
以下定位均锁定本课程版本。先读注释与分支，再深入类型定义。
实现推演
服务器给出未来 10 秒 deadline，通知消耗 4 秒，普通预算已耗尽但允许回退。画出切换、等待与再次请求的顺序，再改成符合专门连接恢复条件的错误，指出计数和等待的区别。
阅读练习无需模型账号。示例命令请先确认目录与环境。
自测与边界检查
会自动增加 max_retries 吗？
展开自测答案
不会，时间与次数分开管理；例外路径有自己的条件。
网络请求恢复能保证写文件工具只执行一次吗？
展开自测答案
不能从该模块作出这种保证。需要结合工具执行记录、历史与目标系统幂等协议核对副作用。