Scala Akka RestartSource onFailuresWithBackoff失效，死信问题求助

1. 异常未传递到RestartSource的监控边界 #

RestartSource仅会对未被内部流处理的异常触发重启。如果你的retryFlow或httpFlow已经通过recover、recoverWithRetries等操作捕获了所有异常，异常不会冒泡到RestartSource，自然不会触发重启逻辑。

• 解决方案：调整错误处理范围，让无法恢复的错误（如连接池崩溃、永久认证失败）抛出到RestartSource层面，仅用RetryFlow处理临时性请求失败（如5xx临时错误）。

2. HTTP错误未转化为流失败 #

Akka HTTP的Http().superPool()或singleRequest()在收到4xx/5xx状态码时，不会自动让流进入失败状态——它会返回包含错误状态的HttpResponse。如果你的代码没有手动判断状态码并触发流失败，RestartSource会认为流是正常完成，不会重启。

• 示例修复：在httpFlow后添加状态码检查

val httpFlow: Flow[HttpRequest, HttpResponse, _] = 
  Http().superPool[HttpRequest]().map {
    case (Success(resp), req) =>
      if (resp.status.isSuccess()) resp
      else throw new RuntimeException(s"Request failed with status: ${resp.status}")
    case (Failure(ex), req) => throw ex
  }

3. 死信源于未清理的旧流资源 #

死信通常是因为RestartSource重启流时，旧的流实例、Actor或连接资源未被正确终止，上游仍在向已失效的组件发送消息。

• 排查点：
  • 检查自定义HttpClient的processRequest方法，确保流被取消时，所有创建的Actor、连接池客户端都能被停止或释放。
  • 确认流的物化值（如run()返回的Future或ActorRef）在RestartSource重启时被正确取消，避免旧资源残留。

4. RestartSource参数配置错误 #

检查onFailuresWithBackoff的参数是否合理：

• maxRestarts是否被误设为0（默认是无限重试，设为0会直接禁用重启）；
• minBackoff/maxBackoff是否过长，导致重启延迟难以察觉；
• 确保randomFactor设置合理，避免重试风暴。
• 示例正确配置：

RestartSource.onFailuresWithBackoff(
  minBackoff = 1.second,
  maxBackoff = 30.seconds,
  randomFactor = 0.2,
  maxRestarts = 10 // 根据业务需求调整
) { () => retryFlow.via(httpFlow) }

5. RetryFlow与RestartSource的职责冲突 #

同时使用RetryFlow和RestartSource时，需明确分工：

• RetryFlow：负责单个请求的重试（如临时网络波动、5xx重试）；
• RestartSource：负责整个流的重启（如流因连接池耗尽、严重系统错误崩溃）。
  如果RetryFlow捕获了所有异常，RestartSource将无异常可感知，不会触发重启。需调整两者的错误处理边界，让严重错误穿透到RestartSource。

新手调试建议 #

• 开启Akka死信日志：在配置文件中设置akka.log-dead-letters = on，查看死信的具体消息和目标Actor，定位残留资源。
• 给流添加日志节点：用log操作记录流的每一步状态和异常，确认异常是否传递到RestartSource层面：

retryFlow.via(httpFlow).log("http-flow-status", identity)

• 简化测试：先去掉RetryFlow，仅用RestartSource包裹基础httpFlow，验证重启逻辑是否生效，再逐步添加RetryFlow排查冲突。

内容的提问来源于stack exchange，提问作者sharingiscaring