Aglet

Verify recovery after API token expiry

A recovery fix must restore access without replaying an unsafe operation or losing the original context. Test an expired read and write separately, include concurrent callers, and inspect replacement storage. Keep the distinction between an issued token and a completed business operation visible in every result.

Check whether the outcome improved

  1. Set expiry outcomes

    Define expected states for valid access, expired access with refresh, rejected refresh, missing replacement storage, and a timed-out write. State which result is safe to retry, which needs readback, and which must remain pending. Record only redacted token metadata.

  2. Exercise one and many callers

    Run the fixtures with a single caller and a small concurrent group. Check that one refresh result is reused appropriately, stale tokens are not sent again, and each operation keeps its own identity. Confirm a rejected refresh becomes a bounded error rather than an unending loop.

  3. Reconcile the original work

    For a write that times out after dispatch, perform the approved readback or review path before retrying. Verify the final local state, attempt count, and correlation record. Repeat after a process restart to catch cache assumptions that a single in-memory test would miss.

What to carry forward

Accept when expiry is detected, recovery is bounded, credentials remain protected, and reads and writes receive the correct retry or reconciliation outcome. Keep coverage partial for remote delivery or revocation behavior that cannot be observed. Retain lifecycle fixtures and the exact client revision.

Technical background: RFC Editor reference.

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