HttpRecorder 会默默丢弃记录的 eval 事件; HTTP 错误响应永远不会在任何失败率下触发回退。

概要 当使用 oaieval --http-run --http-run-url URL 时，HttpRecorder 可能会在没有任何痕迹的情况下静默地丢失已记录的事件，无论在哪个目的地： 1. flush_events 在发送之前将 _written_events 向前推进，因此事件在发送之前就被标记为已写入。 2. 在 _send_event 中，非 OK 的 HTTP 响应（例如从着录端点接收的 500）只会记录一个警告并增加 failed_requests。 该批次永远不会重新发送，也不会写入 local_fallback_path。 3. 启动本地回退的 RuntimeError 只在 except Exception 分支内抛出（连接级错误），而不是在非 OK 响应分支中。因此，以错误状态码回答的端点会丢失所有事件，失败率为 100%，仅记录警告。 4. 即使在异常路径上，阈值将 failed_requests（失败事件的计数）与 len(self._events)（已记录的所有事件）进行比较，然后只在触发阈值的单个批次中启动回退。早期的失败批次仍然丢失。 CLI 帮助将此阈值描述为无害：“5% 的总 HTTP 请求可以失败而不会引起任何问题”。 ## 重现（确定性，仅循环） PoC：f3_httprecorder_silent_drop.py 运行程序：REPRO-http-recorder-silent-event-loss.sh PoC 在 127.0.0.1（临时端口）上启动一个着录服务器，该服务器对包含具有 sample_id 开头的事件的批次进行失败处理，记录包含 200 个匹配事件的 10 个批次，并进行刷新。 在 PIN 上验证： - 所有 20 个批次都被尝试；没有错误出现。 - 确切有 190 个事件到达服务器；具有 poc.drop 开头的 10 个标记事件没有到达任何地方：既没有服务器，也没有回退文件。 - 记录器报告所有 200 个事件已写入（_written_events == 200）。 - 失败比例确切为 5.0%，因此回退永远不会启动。 - 最后一份以 HTTP 500 回答的报告也会被静默丢失，无论失败率为何，因为非 OK 分支无法抛出。 - 只有在服务器关闭（连接错误）后，RuntimeError 路径才会启动，并且它只恢复当前批次；早先丢失的 10 个事件仍然不在回退文件中。 确定性：连续两次运行产生相同的验证输出。 ## 影响 任何使用 --http-run 集中化评估日志（此记录器的宣传用例）的人都可能会发现日志中缺少样本、匹配或整个最终报告，而运行本身则“成功”完成。后期分析从发送的日志中计算的结果会静默地偏离…