Tonic项目中TimeoutExpired错误类型的优化设计

在RPC框架Tonic的开发过程中，错误处理机制的设计是一个关键的技术考量点。近期社区针对TimeoutExpired错误类型的可见性问题提出了改进建议，这个看似简单的改动实际上反映了RPC框架设计中关于错误处理边界的重要思考。

问题背景

Tonic框架当前将TimeoutExpired错误类型定义在transport模块内部，这导致当用户使用自定义传输层实现时，框架无法统一处理超时错误。具体表现为：

1. 内置transport可以正确识别并返回超时错误
2. 但用户自定义transport无法返回相同类型的超时错误
3. 导致框架无法统一处理来自不同transport实现的超时情况

技术分析

TimeoutExpired本质上是一个标记型错误，它不携带额外信息，仅通过类型本身标识"超时"这一事件。这种设计在RPC框架中很常见，因为：

• 超时是分布式系统的基础故障模式
• 需要客户端能够明确区分超时和其他类型的网络错误
• 超时处理通常需要特殊逻辑（如重试策略）

当前实现将其放在transport模块内部，这在框架早期设计阶段是合理的，因为当时transport还未从核心模块分离。但随着架构演进，这种设计显现出局限性。

解决方案

改进方案是将TimeoutExpired提升为框架公共类型：

1. 将类型定义移至tonic顶层模块或error模块
2. 保持其作为简单标记类型的特性
3. 允许所有transport实现（内置或自定义）返回相同类型
4. 框架可以统一处理来自任何transport的超时错误

这种改动带来的好处包括：

• 保持错误处理的一致性
• 不破坏现有代码（非破坏性变更）
• 使自定义transport实现能够与框架更好集成
• 保留测试用例"picks_server_timeout_if_thats_sorter"的预期行为

架构意义

这个改动虽然代码量小，但体现了良好的架构设计原则：

1. 关注点分离：将通用错误类型与具体transport实现解耦
2. 开闭原则：对扩展开放（允许自定义transport），对修改封闭（不改变现有接口）
3. 一致性：所有transport实现遵循相同的错误报告约定

实现建议

在实际实现时，可以考虑：

1. 保持错误类型的极简设计
2. 提供清晰的文档说明其用途
3. 考虑添加便捷的检查方法（如is_timeout_error）
4. 确保错误转换链条保持类型信息

这种设计模式也可以推广到其他类似的标记型错误，为框架未来的扩展奠定良好基础。