pg-boss中处理不可重试错误的正确方式

在使用pg-boss进行任务队列管理时，开发者经常会遇到需要处理任务失败但又不希望系统自动重试的情况。本文将深入探讨如何在pg-boss中优雅地处理这类"不可重试错误"。

问题背景

pg-boss提供了强大的自动重试机制，允许开发者配置任务失败后的重试策略。然而在实际业务场景中，某些错误是"致命性"的，即无论重试多少次都不会成功。例如：

• 业务逻辑校验失败（如订单已取消）
• 权限不足等永久性错误
• 数据完整性被破坏的情况

此时开发者需要一种方式来明确告诉pg-boss："这个任务失败了，但请不要重试"。

解决方案对比

1. 直接删除任务

最直接的方式是调用boss.delete()方法删除当前任务。这种方法简单粗暴，但存在明显缺点：

• 任务记录完全消失，无法追踪历史
• 缺乏失败状态的明确标识
• 不适合需要保留失败记录的审计场景

2. 创建新任务队列

另一种模式是：

1. 删除当前失败任务
2. 创建一个新任务放入专门的"失败处理队列"
3. 新任务携带原始负载和错误信息

这种方法适合需要分级处理的复杂系统，但实现较为繁琐。

3. 使用cancel方法（推荐）

最佳实践是使用boss.cancel()方法：

try {
  // 业务逻辑
} catch (error) {
  if (isFatalError(error)) {
    await boss.cancel(job.id);
    return;
  }
  throw error;
}

这种方法具有以下优势：

• 明确将任务标记为"已取消"状态
• 保留完整任务记录供后续审计
• 状态清晰可区分于普通失败
• API简洁直观

实现建议

对于生产环境，建议实现一个统一的错误处理中间件：

async function handleJob(job, handler) {
  try {
    await handler(job);
  } catch (error) {
    if (error.isFatal) {
      await boss.cancel(job.id);
      // 可选的错误日志记录
      logger.error('Job cancelled due to fatal error', {jobId: job.id, error});
      return;
    }
    throw error; // 非致命错误，触发重试机制
  }
}

// 使用示例
boss.work('queue-name', async job => {
  return handleJob(job, async actualJob => {
    // 实际业务逻辑
  });
});

状态机视角

从pg-boss的状态机角度来看：

• 失败：任务失败，等待重试（retryable）
• 取消：任务明确终止（non-retryable）
• 完成：任务成功执行

这种明确的状态区分使得系统行为更加可预测，也便于监控和报警。

最佳实践

1. 对错误进行明确分类，区分可重试和不可重试错误
2. 对不可重试错误使用cancel而非fail
3. 在任务元数据中记录详细的错误信息
4. 建立监控机制跟踪被取消的任务
5. 考虑实现死信队列处理极端情况

通过合理利用pg-boss提供的状态管理API，开发者可以构建出更加健壮和可靠的任务处理系统。