Aglet

Investigate batch-size changes with a bounded size sweep

A bounded sweep shows whether the change begins at one size and which boundary moves with it. Keep records, ordering, worker pool, and dependencies stable. Trace each batch’s selected identities, resource readings, and commits so correctness and performance conclusions remain tied to the same input.

Build a useful investigation brief

  1. Choose fixed size cases

    Prepare a sanitized ordered input larger than every tested size. Run the previous, current, and one larger size with the same revision and worker conditions. Record expected batch boundaries, item identities, and output effects before starting the sweep.

  2. Trace selection through commit

    Capture query or cursor, selected IDs, per-batch resource readings, checkpoint or transaction boundaries, retries, and committed results. Identify the first size where an item disappears, repeats, or crosses a resource guard. Keep logs correlated to the input revision.

  3. Test one safe range

    Exercise one bounded size limit or cursor adjustment at the first failing boundary and compare coverage, resource use, and resume behavior. If the size is correct but a dependency saturates, document that downstream limit separately rather than expanding the change.

What to carry forward

Deliver the sweep matrix, first correctness or resource divergence, selection and commit trace, and safe-range comparison. State the size and input assumptions behind the brief. Preserve an unresolved distinction when query, memory, and worker evidence point to different boundaries.

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