Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#232 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@NathanTarbert ci sta già lavorando.

Dal 21/9/2026.

  • #281 di @NathanTarbert — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend, distributed-systems, observability

Direzione di ricerca

Inizia tracciando poll(), schedulePoll(), buildHealthResponse, claimAndProcessJobs e job-cleanup.ts, quindi esamina runWithTimeout, JobHandlerContext e stop(). Definisci le modifiche come aspetti separati per il polling, lo stato di salute, la gestione dei job falliti, l'arresto e gli effetti collaterali esterni. Il lavoro è completato quando il conteggio della concorrenza e lo stato di salute rimangono accurati, mentre il comportamento in caso di errore, timeout e arresto è sicuro e delimitato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
12
Fork
6
Merge medio
2h 23m
PR unite (30g)
2

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CopilotKit/outpost

Tutte le issue di CopilotKit/outpost

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.