Aglet

Verify API fallback and recovery behavior

Fallback verification should prove that local continuation matches the confidence of the dependency result. Exercise reads and writes separately, include stale data and process restart, and inspect freshness labels, pending state, and reconciliation. A successful fallback test cannot prove current data.

Check whether the outcome improved

  1. Define dependency outcomes

    Write expected state for healthy response, timeout, connection failure, rate response, permanent rejection, stale fallback, no fallback, and recovered response. Include freshness, retry limit, side-effect policy, and visible next action.

  2. Exercise degraded paths

    Run fixtures through classifier, fallback, pending state, and local consumer. Confirm stale data is labeled, unknown writes are not repeated, and permanent failures do not loop. Compare read and write outcomes with the same dependency failure.

  3. Check recovery and restart

    Restore a healthy response after delay and process restart, then verify reconciliation and freshness update. Ensure old fallback cannot overwrite current data. Retain correlation and state evidence for a dependency that remains unavailable.

What to carry forward

Accept when each dependency state has an intentional local outcome, stale data is visible, unknown writes use reconciliation, and recovery updates state safely. Keep provider or network behavior partial when uncontrolled. Record fixtures, freshness limits, and client revision. Keep stale and current responses distinguishable.

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