RxJS 5.5中retryWhen的状态码提取问题排查

我太懂你这种迁移时卡壳的感觉了——本来好好的代码，换了RxJS 5.5的pipeable operators后，不仅retryWhen里拿不到状态码，错误还变成了字符串，直接打断了业务流程。咱们来拆解问题，一步步修复：

问题根源 #

首先，错误变成字符串大概率是因为你在错误流的某个环节把HttpErrorResponse对象转换成了它的message属性（比如之前的错误处理里用了throwError(e.message)）。而retryWhen的用法在5.5+的pipeable时代也有了更规范的写法，不再是链式调用里直接操作错误流。

解决方案代码示例 #

假设你用的是Angular的HttpClient（从错误信息来看大概率是），下面是迁移后的等价代码，完美适配404作为正常业务场景的需求：

import { of, throwError, timer } from 'rxjs';
import { retryWhen, mergeMap, catchError, take } from 'rxjs/operators';

// 你的putMentor请求方法
const putMentor = () => {
  return this.http.put('/employees/1/mentor', yourMentorData);
};

// 迁移后的调用逻辑
putMentor().pipe(
  // 处理重试逻辑：只对非404错误重试
  retryWhen(errors => 
    errors.pipe(
      mergeMap(error => {
        // 这里确保error是原始的HttpErrorResponse对象，能拿到status
        if (error.status === 404) {
          // 404是正常场景，不重试，直接抛给后续catchError处理
          return throwError(error);
        }
        // 其他错误（比如500）延迟1秒后重试，最多重试3次
        return timer(1000);
      }),
      take(3) // 限制重试次数，避免无限循环
    )
  ),
  // 专门处理404的正常场景，让流程继续
  catchError(error => {
    if (error.status === 404) {
      console.log('404属于正常业务场景，无需中断流程');
      // 返回一个空值或默认数据的Observable，让subscribe的next回调接收
      return of(null); 
    }
    // 非404的错误，继续向上抛出给上层处理
    return throwError(() => new Error(`请求异常: ${error.message}`));
  })
).subscribe(
  result => {
    if (result === null) {
      // 处理404的正常业务逻辑，比如提示“暂无导师信息”
      console.log('未找到该员工的导师信息');
    } else {
      // 处理请求成功的逻辑
      console.log('导师信息更新成功:', result);
    }
  },
  err => {
    // 处理非404的异常错误，比如服务器崩溃
    console.error('请求发生非预期错误:', err);
  }
);

关键注意点 #

1. 保留原始错误对象：绝对不要在错误流中把HttpErrorResponse转换成字符串，比如避免throwError(error.message)，要直接传递原始错误对象，这样才能访问error.status。
2. retryWhen的正确用法：在5.5+中，retryWhen接收的错误流是一个Observable，需要用pipeable operators（比如mergeMap）来逐个处理每个错误，判断是否需要重试。
3. 用catchError消化404错误：把404错误转换成一个正常的Observable返回，这样subscribe的next回调会被触发，流程不会中断，完美契合你的业务需求。

内容的提问来源于stack exchange，提问作者Manuel Santiago Yépez