Aglet

Verify ready jobs claim promptly across worker conditions

Verification should prove the dispatch path under the conditions that expose claim delay. Use the same job shape in a quiet pool, a busy pool, and a controlled lock contention case. Compare queue age and start behavior with the documented threshold, keeping a legitimate capacity wait visible.

Check whether the outcome improved

  1. Verify the quiet path

    Enqueue a ready job while an eligible worker is available. Confirm poll, claim, and start occur in order and that the pre-execution interval meets the documented expectation. Record runtime separately so prompt claim does not hide a slow handler.

  2. Verify a busy pool

    Release the job while workers are occupied and observe the queue, claim, and start records. Confirm the wait is represented as capacity delay and that the job claims when service becomes available. Check that retries do not create a second ready identity.

  3. Verify lock contention

    Hold a known claim lock briefly and enqueue an eligible job. Confirm the job remains visible, does not duplicate its claim, and starts after ownership resolves or enters the documented review state. Reconcile lock and claim identities after completion.

What to carry forward

Accept when quiet, busy, and lock cases distinguish expected capacity from avoidable claim delay, with ready, claim, start, and runtime evidence. Reopen verification if an eligible job misses a free worker, claim records duplicate, or total duration still hides pre-execution waiting.

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