Aglet

Prioritize batch-size regression by correctness and resource risk

A batch-size change is urgent when it omits records or repeats effects; resource regression follows when it consumes shared capacity or causes timeouts. A measurable query increase with correct outcomes may be scheduled for efficiency work. Prioritize correctness and shared-resource consequences before total duration alone.

Decide where the work belongs

  1. Rank coverage before speed

    For each tested size, compare expected and processed identities, terminal outcomes, retries, and checkpoint position. Put omissions and duplicate effects above a slower but correct run. Keep a changed input or unstable ordering out of the correctness claim.

  2. Group resource consequences

    Compare memory, connections, locks, query shape, worker occupancy, and queue age by size. Note which neighboring job classes are affected. A local memory limit needs a different owner from a batch that floods a shared database path.

  3. Choose a safe size decision

    Select immediate rollback or containment, a bounded size sweep, or evidence collection for one missing trace. State the largest size allowed while coverage and resource guards hold. Avoid choosing a new size from a single favorable workload.

What to carry forward

Queue the regression with coverage evidence, resource at risk, affected workload, recovery cost, and size causation confidence. Escalate on skipped or repeated effects or shared-resource failure. Otherwise schedule a matched sweep that can establish a safe tested range.

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