Aglet

Prioritize ready-job claim delay by queue-age impact

Claim delay deserves priority when a ready job’s useful work cannot begin and queue age overwhelms its execution time. A slow job with prompt claim belongs elsewhere. Prioritize blocked actions and repeated pre-execution waits, then distinguish a finite busy-pool condition from a missing poll, routing, or lock handoff.

Decide where the work belongs

  1. Rank waiting versus running time

    For each occurrence, calculate or approximate ready-to-claim, claim-to-start, and execution intervals from recorded events. Name the action delayed by the wait. Put a job that blocks a dependency ahead of one whose queue age is visible but operationally harmless.

  2. Group by pool and boundary

    Compare quiet workers, busy workers, lock contention, queue partitions, and retry-created jobs. Note which boundaries have matched evidence. A pool with no free worker needs capacity review, while a free worker that never sees an eligible job suggests dispatch work.

  3. Choose a bounded dispatch check

    Select immediate investigation, a polling or routing review, or one matched claim trace. State the ready-age evidence that changes priority. Avoid raising worker count before checking whether the delay occurs before workers poll or during a lock attempt.

What to carry forward

Queue the issue with ready age, blocked consequence, queue and worker context, and first waiting boundary. Escalate when eligible jobs repeatedly miss available claim opportunities. Otherwise schedule a matched dispatch investigation and keep runtime latency as a separate measure.

Technical background: Rails guides.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow