Aglet

Triage batch-size regression with matched records and resources

Changing batch size can alter correctness and resource pressure at the same time. Triage the same ordered records at the previous, current, and a larger size. Record selection, query count, memory, claim and commit behavior, and final item coverage so a faster run is not accepted if it skips work.

Establish what is happening

  1. Freeze the input and expected coverage

    Choose a sanitized record set with stable ordering and write expected item identities and outcomes independently. Run the previous and current batch sizes against the same revision. Keep new or deleted records out of the comparison so selection drift remains visible.

  2. Measure query and resource changes

    Capture query count or shape, memory, lock waits, worker time, batch duration, retries, and errors for each size. Mark the first resource or correctness divergence. A high memory reading without lost coverage is different from a missing item caused by cursor movement.

  3. Compare commit and resume behavior

    Inspect per-batch selection, transaction or checkpoint boundaries, committed identities, and final counts. Check whether a larger batch changes retry or resume semantics. Preserve the exact size and ordering where coverage or resource behavior first differs.

What to carry forward

Return fixed input, tested sizes, item coverage, query and resource evidence, first divergence, and checkpoint or commit behavior. Classify the scope as selection, resource ceiling, transaction, retry, or no confirmed regression. Keep causation provisional when size and input revision changed together.

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