Undici 中重试拦截器对 DNS 错误的处理机制解析

在 Node.js 的 HTTP 客户端库 Undici 中，重试拦截器(Retry Interceptor)是一个非常有用的功能，它允许开发者在请求失败时自动进行重试。然而，最近发现了一个值得注意的行为差异：重试拦截器对于 HTTP 错误和 DNS 错误的处理方式并不一致。

问题现象

当使用 Undici 的重试拦截器时，如果遇到 HTTP 状态码错误(如 500 服务器错误)，拦截器会按照预期触发重试回调。但是，当遇到 DNS 解析错误(如 ENOTFOUND)时，重试回调却不会被触发，即使开发者已经在配置中明确指定了要重试的错误码。

技术背景

Undici 的重试机制是通过一系列钩子函数实现的，这些钩子在请求生命周期的不同阶段被调用：

1. onConnect：在建立连接时触发
2. onError：在发生错误时触发
3. onResponseError：在收到错误响应时触发

重试逻辑主要在 onResponseError 钩子中执行，但这里有一个关键条件：只有当控制器(controller)对象存在时才会执行重试逻辑。

根本原因分析

问题的根源在于控制器对象的初始化时机。控制器对象是在 onConnect 钩子中初始化的，这意味着：

• 对于 HTTP 错误：连接已经成功建立，控制器存在，因此可以触发重试
• 对于 DNS 错误：由于无法解析主机名，连接阶段从未开始，控制器未被初始化，导致重试逻辑被跳过

这种设计导致了看似不一致的行为：虽然 errorCodes 配置中包含了 DNS 错误码，但由于控制器缺失，实际上这些错误不会被重试。

解决方案与改进

在最新版本的 Undici 中，这个问题已经被修复。修复方案主要做了以下改进：

1. 移除了对控制器对象的依赖检查，使得重试逻辑能够在更早的阶段执行
2. 确保所有配置的错误码(包括 DNS 错误)都能触发重试回调
3. 保持了原有重试逻辑的其他约束条件，如最大重试次数等

开发者建议

对于需要使用重试功能的开发者，建议：

1. 确保使用最新版本的 Undici 以获得完整的重试功能
2. 明确区分网络层错误(如 DNS)和应用层错误(如 HTTP 500)
3. 根据业务需求合理配置重试策略，包括重试次数和错误码列表
4. 对于关键业务，考虑添加额外的错误处理逻辑作为重试机制的补充

总结

Undici 的重试拦截器设计体现了网络请求处理的复杂性。理解不同层次错误(网络层 vs 应用层)的处理机制对于构建健壮的 HTTP 客户端至关重要。这次问题的修复使得重试行为更加符合开发者的预期，为构建可靠的分布式系统提供了更好的基础。