Aglet

Investigate job claim delay with quiet and busy controls

A claim investigation must show where a ready job waits before execution begins. Use equivalent jobs in a quiet pool, a busy pool, and a lock-contended case. Trace the same event sequence and compare first eligible, poll, lock, claim, and start times rather than relying on total job age.

Build a useful investigation brief

  1. Prepare matched ready jobs

    Create sanitized jobs with the same queue, payload shape, and eligibility. Release one when the pool is quiet and another while workers are busy. Record expected ready times and use distinct IDs so queue order and retry state remain visible.

  2. Trace poll, route, and lock

    Capture scheduler or worker poll, queue assignment, eligibility check, lock attempt, claim record, and start. Identify the first boundary where the job is delayed. If no worker was available, record capacity; if a worker was free, inspect polling and routing evidence.

  3. Test one claim boundary

    Exercise one bounded polling, assignment, or lock adjustment in the same controls. Compare ready-to-claim and claim-to-start intervals without changing job runtime. Keep any residual wait tied to the remaining boundary rather than calling the entire queue healthy.

What to carry forward

Deliver quiet, busy, and lock-contended traces, first waiting boundary, and one dispatch comparison. State whether the next work belongs to poll cadence, routing, lock ownership, worker capacity, or execution. Keep missing event timestamps and job eligibility assumptions explicit.

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