fix:correctly identify channel errors with channel_error type

[chenzhenhua016]

No description provided.

[szl97]

@claude 检查提交的代码，使用中文回复

[szl97]

Claude finished @szl97's task —— View job

---

代码检查任务

• 分析PR中修改的14个文件
• 检查错误类型标识的修改是否正确
• 验证代码一致性和最佳实践
• 提供详细的代码评审反馈

代码评审结果

✅ 修改总结

本次PR主要将所有错误处理中的错误类型从非标准字符串（如 response.message()、bedrockException.getMessage() 等）统一修改为标准的 "channel_error" 类型，以便系统能够正确识别和处理渠道错误。

✅ 积极方面

1. 一致性改进：所有 ChannelException.OpenAIException 的错误类型参数都统一使用了 "channel_error" 字符串，确保了系统错误处理的一致性。

2. 覆盖全面：修改涵盖了多个协议适配器：

   • ASR适配器（火山引擎、腾讯）
   • TTS适配器（火山引擎）
   • 文档解析适配器（Lark）
   • 消息适配器（Anthropic、AWS）
   • 实时通信适配器
   • HTTP工具类

3. 符合系统设计：统一的错误类型便于上层系统进行错误分类和处理。

⚠️ 需要关注的问题

1. 错误信息丢失风险

BellaStreamCallback.java:48 和类似位置：

// 修改前：可能包含具体的HTTP状态信息
new ChannelException.OpenAIException(response.code(), response.message(), response.message())

// 修改后：统一但可能丢失细节
new ChannelException.OpenAIException(response.code(), "channel_error", response.message())

建议：虽然统一了错误类型，但建议确认 response.message() 仍作为错误详情传递，避免丢失重要的调试信息。

2. 日志记录一致性

各个文件中的错误处理日志级别和格式存在差异：

• 有些使用 log.error
• 有些使用 log.warn
• 有些包含异常堆栈，有些不包含

建议：统一渠道错误的日志记录标准，特别是确定何时需要记录异常堆栈。

3. HTTP状态码映射

HuoshanStreamAsrCallback.java:456 等位置的状态码映射逻辑较为复杂：

private int getHttpCode(int code) {
    if(code == 1000) return 200;
    if(code == 1002) return 401;
    // ...
}

建议：考虑将这类状态码映射逻辑提取为工具类，提高代码复用性和维护性。

✅ 代码质量评估

1. 安全性：✅ 良好 - 没有发现安全风险
2. 性能：✅ 无影响 - 仅修改字符串常量
3. 可维护性：✅ 提升 - 统一的错误类型便于维护
4. 测试覆盖：⚠️ 建议验证错误处理的单元测试是否需要更新

🎯 总体评价

这是一个高质量的代码重构，成功解决了错误类型标识不一致的问题。修改范围广泛但逻辑清晰，有助于系统错误处理的标准化。

推荐合并，但建议：

1. 确认相关的错误处理测试用例已相应更新
2. 在生产环境部署后监控错误日志，确保错误信息仍然足够详细用于问题排查

---