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

worker: stop awaiting each claim batch, so concurrency limits and /health mean something

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

メンテナーはふだん 7 日以内に返信

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
活発
技術スタック
typescript
領域
backend, distributed-systems, observability

調査の方向性

まず poll()、schedulePoll()、buildHealthResponse、claimAndProcessJobs、job-cleanup.ts を追跡し、次に runWithTimeout、JobHandlerContext、stop() を調べます。変更は、ポーリング、ヘルス、失敗したジョブの処理、シャットダウン、外部副作用について、それぞれ分離した関心事として定義します。完了の条件は、並行実行数の計上とヘルスが正確なまま維持され、失敗、タイムアウト、シャットダウン時の動作が安全かつ有界であることです。

索引モデルが issue の本文から書いたものです。

説明

area: infrastructure bug roadmap roadmap: next

From the review of #224. These are the items that PR deliberately left out, and the first one is load-bearing for two others.

The batch await makes concurrency accounting dead code

poll() fully awaits Promise.allSettled over each claimed batch, and schedulePoll only runs after the poll resolves. So activeJobs.size and activeJobsByType are always 0 when availableSlots and typeLimit - activeForType are computed. Both expressions are unreachable: mutating each to ignore in-flight work passes the whole suite.

It does not over-fetch — the serialization accidentally bounds it — but per-type concurrency limits never bind, which is not what concurrencyByType looks like it does.

Which is also why /health is still wrong (#182, #184)

Because poll() blocks for the whole batch duration, lastPollTime stalls for as long as the longest job. buildHealthResponse compares it against STALE_POLL_MS = 60_000 with no active-job exemption, against a 120s AI_RESPONSE timeout. So a healthy worker mid-job returns 503 "stalled" and Railway restarts it — killing the job it was in the middle of.

Two ways out, and they should be decided together:

  1. Stop awaiting the batch (fixes the accounting too), or
  2. Exempt active jobs from the stale-poll check.

(1) is the better fix and makes (2) unnecessary. This is the reason /health has now been deferred three times; it should be one PR with the batch change.

An unregistered job type is terminally destroyed

FAILED with completedAt and no attempt increment — and job-cleanup.ts only deletes COMPLETED and DEAD_LETTER, so the rows accumulate forever. #224 added lockedAt: null, claimToken: null to that write, which means reclaim can't rescue them either.

Reachable only via claimAndProcessJobs, and production sets concurrencyByType so it takes the type-filtered path. Latent today; live the moment concurrencyByType is emptied or a worker ships without the full handler set.

A no-op release back to PENDING with no attempt consumed is the safe failure. Data-destroying path, so it wants its own change.

The timeout doesn't cancel the handler, and the drain has no deadline

runWithTimeout stops waiting for the handler; the handler keeps running. And AI_RESPONSE at 120s against Railway's ~30s SIGTERM grace means the graceful drain resolves well after SIGKILL already landed.

So the real shutdown path is still crash-abandonment plus reclaim. #224's fence makes that safe at the row level — it is not cancellation, and shouldn't be read as such. Threading an AbortSignal through JobHandlerContext is the actual fix.

Handlers with external side effects need idempotency keys

A database fence can't un-send an email. In an interleaving where a live claim is reclaimed, the first execution's external effects have already happened. lockUntil (#224) makes that much rarer, not impossible.

  • AI_RESPONSE — covered by #191's Message.ticketId_responseKey and the responseState machine.
  • ESCALATION, HUBSPOT_SYNC, TRACKER_SYNC — not covered, and #224 is what introduces automatic re-execution.

Smaller

  • void currentPoll.finally(cb) builds a derived promise with no rejection handler. poll() can't reject today, so latent — but if a throw ever escapes it's an unhandled rejection, and stop()'s await this.pollPromise would propagate out so $disconnect() never runs.
  • job-cleanup.ts never deletes FAILED rows at all, which is what makes the accumulation above unbounded.
主要言語
TypeScript
スター
8
フォーク
4
平均マージ
5日 4時間
マージ済み PR（30日）
11

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

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

CopilotKit/outpost のほかの issue

CopilotKit/outpost の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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