packages/outpost/queue/src/worker.ts has a branch that marks a job FAILED with "No handler registered for job type: X". Under per-type claiming that branch is unreachable in production: the claim query only asks for types that have a registered handler, so a job of an unregistered type is never claimed at all. It sits PENDING forever — no failure, no dead letter, no log.
This is live today: TICKET_CLASSIFY has no handler registered in apps/worker/src/index.ts. Anything that enqueues it accumulates silently.
Two things to decide:
- Should an unregistered type fail loudly (claim it and mark
FAILED, matching the existing branch's intent) or be swept by a periodic reaper?
- Is
TICKET_CLASSIFY still wanted? handleAiResponse performs classification inline, so the separate job type may be vestigial — in which case remove it from JobType rather than leaving a job type nothing consumes.
Found by: CR round 2 on #150 (slots 1-2, 2-1, 4-1, 5-1).
packages/outpost/queue/src/worker.tshas a branch that marks a jobFAILEDwith "No handler registered for job type: X". Under per-type claiming that branch is unreachable in production: the claim query only asks for types that have a registered handler, so a job of an unregistered type is never claimed at all. It sitsPENDINGforever — no failure, no dead letter, no log.This is live today:
TICKET_CLASSIFYhas no handler registered inapps/worker/src/index.ts. Anything that enqueues it accumulates silently.Two things to decide:
FAILED, matching the existing branch's intent) or be swept by a periodic reaper?TICKET_CLASSIFYstill wanted?handleAiResponseperforms classification inline, so the separate job type may be vestigial — in which case remove it fromJobTyperather than leaving a job type nothing consumes.Found by: CR round 2 on #150 (slots 1-2, 2-1, 4-1, 5-1).