Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Feature: limit how many times a stalled job is recovered

オープン
  • 何か問題がありますか？
#53 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
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 ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

platformatic/job-queue のほかの issue

platformatic/job-queue の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。