Aglet

Document job output retention and reader recovery

The lasting lesson is that output retention must match the reader’s job and expose the end of availability. Document the output key and revision, the expiry decision, and what a reader or downstream step does afterward. Keep rebuilding separate from retrieving the original completed result.

Keep the lesson for the next incident

  1. Name the retention contract

    State when output becomes available, how expiry is calculated, what metadata remains, and which readers may rely on it. Define unavailable, rebuilding, and regenerated states. Tie expiry to the job and output revision so a new result cannot hide an old one.

  2. Retain reader fixtures

    Keep in-window, boundary, post-expiry, slow-reader, and rebuild cases with expected IDs, messages, and downstream decisions. Re-run them after changing output size, storage, cache, retention period, reader latency, or regeneration behavior.

  3. Watch recurrence signals

    Review completed jobs whose output expires before the expected reader, keys that point to a missing revision, and downstream steps that treat empty output as success. Compare creation and read times before extending retention. Assign review when a new output class lacks a recovery rule.

What to carry forward

Preserve a retention and reader contract with output identity, expiry evidence, and explicit rebuild or empty states. Recurrence checks should connect completion, availability, and reader timing. Reopen review when output class, storage, cache, reader latency, or regeneration changes what a completed result means.

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