Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Feature: limit how many times a stalled job is recovered

未关闭
  • 哪里不对？
#53 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
node.js, typescript
领域
backend, distributed-systems

调研方向

Start with Reaper's #recoverStalledJob and the requeue() path, then inspect job state handling and the enqueueAndWait failure path; DESIGN.md documents the at-least-once behavior. Run the provided stalled-handler reproduction, and consider the work done when a maxStalledCount limit produces the requested stored error, TTL, failed event, and JobFailedError behavior.

由索引模型根据 Issue 内容生成。

描述

Running a job again after a stall is expected: the queue is at-least-once, and DESIGN.md says jobs "may be processed multiple times after crashes, lease expirations". But nothing limits how many times the same job is recovered. A job that reliably hangs or crashes its worker (a "poison" job) is recovered and re-run indefinitely, tying up a worker each time and never reaching a terminal state. maxAttempts doesn't help, because it only counts handler failures, and a stalled job never produces one.

Example

@platformatic/[email protected] (also on main). The handler ignores cancellation and never settles, so every run stalls:

import { MemoryStorage, Queue, Reaper } from '@platformatic/job-queue'
import { setTimeout as sleep } from 'node:timers/promises'

const visibilityTimeout = 500
const storage = new MemoryStorage()
const queue = new Queue({ storage, visibilityTimeout, concurrency: 10 })
const reaper = new Reaper({ storage, visibilityTimeout })

// The handler ignores cancellation and never settles, so every run stalls.
let runs = 0
queue.execute(job => {
  console.log(`run #${++runs}: job.attempts = ${job.attempts}`)
  return new Promise(() => {})
})

await queue.start()
await reaper.start()
await queue.enqueue('stuck', {}, { maxAttempts: 1 })

await sleep(visibilityTimeout * 4 + 200)
console.log(`maxAttempts was 1, the job ran ${runs} times`)

await reaper.stop()
await queue.stop()
await storage.disconnect()

run #1: job.attempts = 1
run #2: job.attempts = 1
run #3: job.attempts = 1
run #4: job.attempts = 1
run #5: job.attempts = 1
maxAttempts was 1, the job ran 5 times

(The count here is capped by the 10 consumer slots the stuck handlers occupy. A job that crashes its worker process would instead be recovered after every restart.)

Proposal

Add a limit on stall recoveries, e.g. a maxStalledCount option, as BullMQ has. When a job exceeds it, fail it the same way as a final handler failure: store an error, apply the error TTL, emit failed, and reject enqueueAndWait callers with JobFailedError.

Implementation notes

  • The count has to be stored with the job and updated together with the requeue. Putting it in the message is awkward, because requeue() finds the processing entry by the original message bytes. So the job state is probably the better place.
  • #recoverStalledJob already writes failing:<ts>:<attempts + 1> into the state, but nothing reads the incremented value. That could become the stall counter, or the + 1 could be dropped.
  • Recovery requeues the job first and writes its state afterwards. Doing both atomically would keep it from overwriting a state written in between.

I'm happy to send a PR for this.

主要语言
TypeScript
星标
371
派生
11
30 天内没有已合并 PR

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

platformatic/job-queue 的其他 Issue

查看 platformatic/job-queue 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。