Aglet

Investigate job output expiry with delayed reader fixtures

Investigation should separate output creation from retention and retrieval. Use one fixed completed job and issue reads before expiry, at the boundary, and after expiry. Trace the stored key, metadata, retention decision, and fallback so the brief identifies premature deletion, wrong identity, or an expected window without a reader signal.

Build a useful investigation brief

  1. Create one output with known timestamps

    Run a sanitized job whose output revision and source input are recorded. Capture creation, retention or expiry decision, storage key, and terminal state. Avoid changing the output while testing reads so a new revision cannot masquerade as expiry.

  2. Trace reads across the window

    Issue controlled reads inside the window, at its boundary, and after expiry. Record response, metadata, cache behavior if visible, and reader message. Compare application status with storage evidence and preserve any clock disagreement as a separate finding.

  3. Test the recovery path

    Exercise the documented rebuild, rerun, or empty-state response after expiry. Compare identity, user-visible status, and downstream eligibility with an immediate read. If rebuilding changes the source or side effects, document that limitation rather than presenting it as an equivalent result.

What to carry forward

Deliver creation and expiry timestamps, read responses, key and revision trace, and one recovery comparison. State whether the next work belongs to retention, identity, reader timing, or rebuild semantics. Keep a completed job with no source or unclear expiry as an explicit unresolved risk.

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