Aglet

Investigate stale notification links with state replays

An investigation should show what changed between notification creation and click and whether the destination still helps. Replay current and changed targets, vary role or resource state, and inspect the fallback. Keep routing, permission, and stale-content explanations separate. A safe fallback still needs enough context to continue.

Build a useful investigation brief

  1. Build the stale-link matrix

    List identifier, event time, original state, current state, role, action, destination, response, copy, parent context, and recovery. Include a current target, changed target, and permission-limited target. Use stable references rather than private content.

  2. Trace the first failure

    Change one resource state or role at a time and compare destination, status, explanation, and action. Record whether the link resolves to old content, a useful current view, or a generic error. Preserve a current link as control.

  3. Write the recovery brief

    State first stale boundary, affected event class, fallback requirement, and competing explanations. Recommend one bounded destination or copy experiment with a pass condition. Do not claim the resource is deleted when the evidence only shows unavailable access.

What to carry forward

The investigation is complete when changed target behavior and fallback are reproducible for selected states and roles. Stop with one recovery experiment. Keep routing and permission boundaries visible so a stale-link repair does not overclaim all failures.

Technical background: Apple developer documentation.

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