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

Keep a timed-out handler visible after runWithTimeout stops waiting for it

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
backend, observability

調査の方向性

packages/outpost/queue/src/worker.ts から始め、runWithTimeout、processJob、activeJobStarts、WorkerHealthStatus のパスを追跡します。提案されている孤児化した handler の追跡とタイムアウトのログ出力を、既存の health response および失敗処理と比較します。タイムアウトした handler が引き続き観測可能であり、health が orphanedHandlerCount を報告し、worker が合意したしきい値で 503 を返すことが完了条件です。

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

説明

area: infrastructure roadmap: next

runWithTimeout in packages/outpost/queue/src/worker.ts is a Promise.race between the handler and a timer. The race settling does not cancel the handler, so on a timeout the job is marked failed, processJob's finally frees the slot and deletes the job's entry from activeJobStarts — and the handler keeps running.

That matters more since #262, because overdueJobCount is measured from activeJobStarts. An orphaned handler is removed from the map at the moment it becomes orphaned, so the count is zero by construction for exactly the work that escaped its timeout. The docstring on that field says a non-zero count means the timeout machinery failed; this is a failure of the timeout machinery that it cannot see.

What it looks like in production

The LLM provider stalls, with no AbortSignal on the pipeline's fetch. Every AI_RESPONSE job times out at 120s, handleFailure schedules a retry, and the poll immediately claims more. Each bad job leaves an orphan behind and is retried up to maxAttempts, so orphans accumulate — each holding a socket and a connection-pool checkout.

Steady state after ten minutes is a worker running noticeably more work than it believes it is, while /health answers 200 {"status":"ok"} and activeJobCount reports only whatever is currently raced. The eventual symptom is pool exhaustion surfacing as an unrelated Prisma error somewhere else entirely, which is a long way from the cause.

Shape of a fix

Keep the orphan visible rather than deleting it:

const started = this.activeJobStarts.get(job.id);
void promise.finally(() => this.orphanedHandlers.delete(job.id));
this.orphanedHandlers.set(job.id, started);

Publish orphanedHandlerCount on WorkerHealthStatus and answer 503 above a threshold — >= maxConcurrency is a defensible line, since past it the worker is running more work than it thinks it is. At minimum, console.error on every timeout naming the job id and type: today the only record is the console.warn inside handleFailure, which describes a retry rather than an abandoned handler.

The deeper fix is an AbortSignal threaded through the handler contract so a timeout actually stops the work. That is a larger change to a shared package and worth doing on its own.

Pre-existing on main; #262 neither introduced nor worsened it. Filed because #262's docs now reference the limit, and a documented limit with no tracking behind it tends to become a documented permanence.

主要言語
TypeScript
スター
13
フォーク
6
平均マージ
4時間 49分
マージ済み PR（30日）
3

環境構築

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

はじめの一歩

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

CopilotKit/outpost のほかの issue

CopilotKit/outpost の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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