Aglet

Document the job priority and queue boundary contract

The durable lesson is where priority is interpreted and where it stops applying. Record how a label travels from enqueue to selection, whether precedence is queue-local, and what happens to ties or already claimed work. Keep those semantics beside queue configuration so a new worker class does not create an invisible exception.

Keep the lesson for the next incident

  1. Write the dispatch rule

    Name the fields used for selection, the queues in scope, and the point at which a job becomes committed to a worker. State what priority does not preempt, including in-flight work if applicable. Link the rule to ready, claim, and start timestamps.

  2. Retain priority fixtures

    Keep matched urgent and ordinary jobs, queue-boundary cases, ties, and late arrivals with expected claim order. Re-run them after changing queue topology, worker eligibility, selector code, or job metadata propagation.

  3. Watch for recurrence

    Review urgent jobs whose ready-to-claim age exceeds the documented comparison while lower-priority eligible jobs claim first. Inspect queue and worker context before escalating. Assign ownership when a new job class or queue changes the set of work competing for precedence.

What to carry forward

Preserve a priority propagation rule, explicit queue scope, tie behavior, and matched dispatch fixtures. Recurrence checks should compare eligible ready jobs with claim order, not completion order. Reopen review when a new worker class, queue, or job field changes who competes for priority.

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