Aglet

Prioritize starvation by maximum wait and service consequence

Starvation becomes a queue problem when a valid job can wait indefinitely while favored work keeps receiving service. Prioritize the oldest confirmed wait and what it prevents, then examine whether the same class or tenant is repeatedly excluded. A busy pool with no available slot needs capacity work before fairness work.

Decide where the work belongs

  1. Rank the oldest blocked outcome

    Record the oldest low-priority job, its intended result, and any dependent work waiting on it. Compare the age with the documented service expectation. Put a job that prevents reconciliation or maintenance ahead of one that has a flexible completion date.

  2. Confirm repeated bypasses

    Count observed opportunities where a worker was available and a favored arrival claimed instead. Keep mere queue occupancy separate from selector decisions. Group by job class and worker pool so a single isolated delay does not stand in for systemic starvation.

  3. Choose a fairness experiment

    Select immediate investigation, an aging or reserved-capacity design review, or one bounded arrival replay. State the maximum wait or missed-service evidence that changes priority. Do not lower all favored work blindly; preserve the work mix that demonstrates the failure.

What to carry forward

Queue starvation using oldest confirmed wait, blocked consequence, repeated bypass evidence, and worker availability. Escalate when an eligible job misses service repeatedly under a sustained stream. Otherwise schedule a controlled arrival experiment and keep capacity shortage as a separate queue item.

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