Aglet

Triage queue fairness drift with per-class service records

Fairness can drift gradually while total throughput appears healthy. Triage the classes competing for service, using the same interval and worker pool. Compare each class’s ready work with its claims and completions, then inspect whether a new queue, priority, or workload mix changed the service boundary.

Establish what is happening

  1. Build per-class counts

    For one bounded interval, record ready, claimed, active, completed, and failed jobs by class or tenant. Include oldest wait and worker pool. Avoid using total queue depth as a fairness measure because a large class can hide another class’s disappearance.

  2. Compare service share over time

    Split the interval into earlier and later windows and compare class-specific claim and completion shares. Mark whether ready volume also changed. A falling share with stable eligibility is stronger drift evidence than a falling share caused by no arrivals.

  3. Inspect the partition boundary

    Review queue assignment, priority labels, worker reservations, and selector changes around the first divergence. Compare a class that retained service with one that lost it. Preserve configuration and trace timestamps so a workload shift is not mistaken for a policy change.

What to carry forward

Return class-specific ready and service records, oldest waits, worker context, first drift interval, and possible partition changes. Classify the scope as arrival mix, capacity, queue assignment, or selector behavior. Keep drift unconfirmed where a class had no eligible work to serve.

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