Aglet

Prioritize scheduled overlap by duplicate effect risk

Overlap is urgent when two occurrences can produce the same durable effect or leave one output owner unknown. Parallel work that is explicitly allowed may only need clearer status. Prioritize effect risk and recurrence, then the schedule family and worker capacity exposed by the overlap.

Decide where the work belongs

  1. Rank competing effects

    For each pair, list shared output keys, writes, messages, external calls, and any idempotency record. Put an overlap that can repeat a non-idempotent effect ahead of two read-only runs. Keep resource contention visible when the outputs are safe but the queue is displaced.

  2. Check policy and persistence

    Compare observed overlap with the documented skip, queue, lock, or concurrent policy. Group by schedule interval and runtime shape. A single long run may be expected to overlap under a concurrent policy, while repeated collisions after a lock expiry indicate a narrower failure.

  3. Choose a contained next step

    Select immediate reconciliation, a lock or policy review, or one slow-run fixture. Name the output readback and run identity required before another occurrence is allowed. Avoid adding a blanket lock before understanding whether queued overlap is the intended recovery behavior.

What to carry forward

Queue overlap using duplicate-effect risk, policy violation evidence, output ownership, and recurrence. Escalate when a second run can write the same result without an idempotency decision. Otherwise schedule a slow-run investigation that exercises the documented overlap policy and lock lifetime.

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