OperationService billing requests have no timeout or status handling

快速结论：该问题通常出现在自部署 Dify 环境，当 OperationService._send_request() 向计费（billing）或 UTM 端点发送请求时，未设置请求超时（timeout）且未对非 2xx 或非 JSON 响应做错误处理。优先排查 BILLING_API_URL 指向的服务是否可用，以及 api/services/operation_service.py 中 httpx.request() 调用是否缺少 timeout 参数和 raise_for_status() 调用。

问题场景

用户在自部署 Dify（Self Hosted Source）环境下，通过代码审查发现当前 main 分支的 API 服务存在缺陷。当触发 UTM 记录路径（调用 OperationService.record_utm()）时，如果 BILLING_API_URL 指向一个慢速端点，或计费服务仅接受 TCP 连接但未及时响应，Flask 工作线程会因 httpx.request() 未设置显式超时而挂起；同时，非 2xx 或非 JSON 的响应会直接通过 response.json() 解析，导致泛化的 JSON 解析失败。

报错原文

# api/services/operation_service.py
response = httpx.request(method, url, json=json, params=params, headers=headers)
return response.json()

实际运行时可能表现为：

httpx.TimeoutException: 请求超时
或
json.JSONDecodeError: 非 JSON 响应解析失败

但原代码未捕获这些异常。

原因分析

可能原因：OperationService._send_request() 方法在发送计费/UTM 请求时缺乏三个关键保护机制：

缺少显式超时：httpx.request() 调用未传入 timeout 参数，导致网络请求可能无限等待。
缺少状态码验证：未调用 response.raise_for_status()，非 2xx 响应会被直接当作 JSON 解析。
缺少 JSON 解析前的内容验证：若响应体不是 JSON 格式（如 HTML 错误页），直接调用 response.json() 会抛出 JSONDecodeError。

对比同仓库的 api/services/billing_service.py，后者已通过连接池（pooled HTTP client）、状态码逐方法校验和 @retry 装饰器解决了这些问题，但 operation_service.py 未同步改进。

环境排查

Dify 版本：当前 main 分支（通过代码审查确认）。
部署方式：Self Hosted (Source)。
需检查 BILLING_API_URL 环境变量指向的计费服务是否正常运行。
需确认 Python 版本（依赖 httpx 库）。
建议检查 api/services/operation_service.py 文件第 25-31 行左右的代码。

解决步骤

定位问题文件：打开 api/services/operation_service.py，找到 _send_request() 方法。

添加请求超时：将 httpx.request() 调用修改为使用显式超时：

import httpx
timeout = httpx.Timeout(10.0, connect=3.0)
response = httpx.request(method, url, json=json, params=params, headers=headers, timeout=timeout)

添加状态码校验：在解析 JSON 前检查 HTTP 状态码：

if response.status_code != httpx.codes.OK:
    logger.error("operation_service: %s %s returned %s: %s", method, url, response.status_code, response.text)
    raise ValueError(f"Billing request failed with status {response.status_code}")

安全解析 JSON：确认状态码为 200 后再调用 response.json()。
（可选）迁移为连接池+重试模式：参考 api/services/billing_service.py 的实现，将 OperationService 改为使用相同的池化客户端（pooled client）+ tenacity 重试装饰器。PR #34311 和 #35600 已对 billing_service.py 做过类似升级。

验证方法

部署修改后，通过以下方式验证：

在配置了慢速或不可达 BILLING_API_URL 的环境下触发 UTM 记录路径（如执行需要 UTM 跟踪的操作），观察请求是否在 10 秒内超时返回，而非无限等待。
检查 Flask 工作线程日志中是否记录了类似 operation_service: POST ... returned 503: ... 的错误信息。
确认非 2xx 响应不再导致 JSONDecodeError，而是被正确捕获并记录。