BullMQ Worker就绪后不执行任务且重复任务配置失效问题排查

首先我帮你拆解这两个问题的根因和解决办法，先从你已经定位到的Worker不执行任务的问题说起：

一、Worker就绪但不执行任务的根因 #

你后续更新提到「catch块里抛出了自定义错误导致应用崩溃」，这确实是核心问题：

• 你的Worker虽然打印了就绪日志，但进程在调用failedBullMQ之后直接崩溃了，Worker进程都不存在了，自然无法执行任何任务逻辑
• 这个坑很容易被忽略，因为如果自定义错误没有被全局捕获，进程退出的日志可能被淹没在其他输出里，不容易被第一时间发现

修复建议 #

• 如果必须在catch块里抛出错误，一定要在进程层面添加全局错误捕获，避免进程直接退出：

  // 在项目入口文件添加全局错误监听
  process.on('uncaughtException', (err) => {
    console.error('未捕获的异常:', err);
    // 可根据需求添加优雅重启、告警等处理
  });
  
  process.on('unhandledRejection', (reason, promise) => {
    console.error('未处理的Promise拒绝:', reason);
  });
  

• 或者调整业务逻辑：把任务放入队列后，只记录错误日志即可，不需要抛出错误导致进程崩溃——毕竟已经有失败队列兜底处理了

二、重复任务与重试配置失效的问题 #

这个问题源于你对BullMQ的「重复任务」和「重试任务」机制的理解偏差，再加上代码里的几个细节问题共同导致的：

1. repeat和attempts/backoff的逻辑冲突 #

BullMQ里重复任务和重试任务是完全独立的两个功能：

• 「重复任务（repeat）」：按照固定时间间隔，反复创建新的任务实例，不管上一个任务成功还是失败
• 「重试任务（attempts/backoff）」：单个任务失败后，按照退避策略重试当前任务，最多重试指定次数

你同时配置了这两个机制，会导致：

• 重复任务每隔2分钟生成一个新任务，每个任务失败后又会触发10次重试，队列里会塞满大量冗余任务
• 重试的3.5秒退避和重复的2分钟间隔互相干扰，完全打乱你预期的执行节奏

针对不同需求的修复方案：

• 如果你的需求是任务失败后，每隔2分钟重试一次，最多试10次：完全不需要repeat，只需要把退避时间改成2分钟即可

  // 修改createQueue中的defaultJobOptions
  const options: Partial<QueueOptions> = {
    defaultJobOptions: {
      removeOnComplete: true,
      removeOnFail: false,
      attempts: 10,
      backoff: { type: "fixed", delay: 2 * 60000 } // 改为2分钟退避
    }
  };
  // 同时去掉queue.add里的repeat配置
  await queue.add("retry-jobs", data, {
    jobId: `${uniqueQueueName.split("-")[1]}-${Date.now()}`
  });
  

• 如果你的需求是不管任务成功失败，每隔2分钟执行一次：去掉attempts和backoff配置，只保留repeat，同时要保证业务逻辑的幂等性（避免重复执行相同操作导致数据异常）

2. JobId重复导致任务无法正常添加 #

你生成JobId的方式是uniqueQueueName.split("-")[1].concat(new Date().toDateString())，比如UpdateUserDataWed Oct 11 2024，这个ID同一天内完全重复。BullMQ默认不会添加重复JobId的任务，所以同一天内多次调用failedBullMQ，只有第一个任务能被加入队列，后续的都会被静默忽略。

修复方法：给JobId加上时间戳，保证全局唯一性：

jobId: `${uniqueQueueName.split("-")[1]}-${Date.now()}`

3. 处理器递归调用的风险 #

你把updateUserDataController作为处理器传给failedBullMQ，这会导致无限递归加入队列：

• updateUserDataController失败 → 调用failedBullMQ → 加入队列 → Worker执行updateUserDataController → 失败后又调用failedBullMQ → 循环往复

正确的做法是把业务逻辑和队列逻辑彻底拆分：

// 1. 纯业务逻辑函数：只做数据库更新，不包含队列相关代码
async function updateUserData(data: any) {
  // 这里只写数据库更新的核心逻辑，比如await updateQuery(data);
}

// 2. 控制器函数：处理请求、调用业务逻辑、失败后放入队列
export async function updateUserDataController(data: any) {
  try {
    await updateUserData(data);
  } catch (error) {
    // 把纯业务函数作为处理器传入，而不是控制器本身
    await failedBullMQ("Failed-UpdateUserData", data, updateUserData);
    console.log("something went wrong. the data are moved to the queue.");
  }
}

最后总结 #

• Worker不执行任务：核心是进程崩溃，要确保进程在任务入队后不会意外退出
• 配置失效：搞清楚重复任务和重试任务的区别，根据业务需求二选一，同时修复JobId重复和处理器递归的问题

内容来源于stack exchange