Aglet

Investigate scheduled overlap with a deliberately slow run

Investigation should hold the schedule rule stable while making one run last beyond the next due time. Trace the first run, the due event, and the second occurrence through the overlap guard. Compare the observed outcome with the policy and verify effects by durable identity, not by log order alone.

Build a useful investigation brief

  1. Prepare finish-before and span-interval cases

    Create a sanitized schedule whose first run finishes before the next due time, then repeat with a controlled pause that spans it. Record expected skip, queue, or concurrent behavior and use distinct occurrence IDs for every run.

  2. Trace guard decisions

    Capture due, enqueue, claim, lock acquisition, lease renewal or expiry, start, and terminal records for both occurrences. Identify the first point where the second run is admitted or rejected. Preserve output keys and side-effect records for reconciliation.

  3. Test one overlap policy

    Exercise one explicit skip, queue, lock, or concurrent rule in the same fixture. Compare the second occurrence’s state, wait, and eventual output with the original policy. Keep lease-expiry behavior separate if it is a different recovery boundary.

What to carry forward

Deliver the slow-run pair, guard trace, first admission decision, and output reconciliation. State whether the next work belongs to scheduler policy, lock lifetime, queueing, or intentional concurrency. Include a recovery rule for a second occurrence already admitted before the guard changed.

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