Aglet

Verify stable API error handling after a contract change

Error handling is verified when known classes remain useful and unknown responses fail safely. Exercise status, media type, structured fields, malformed bodies, and delayed responses through the real decoder. Test reads and writes separately because the same fallback can be safe for one and dangerous for the other.

Check whether the outcome improved

  1. Define response dispositions

    Write expected action for validation, authorization, rate, server, empty, malformed, and unknown responses. Include retry limit, local state, visible message, and correlation data. State what the client must never do, such as retry an unknown write without operation identity.

  2. Run the error matrix

    Feed each fixture through the updated decoder and compare status, typed branch, preserved safe detail, and retry choice. Verify a new field or code does not fall into a success path. Check that non-JSON or proxy responses remain distinguishable from application errors.

  3. Exercise recovery paths

    Repeat a representative read and write after each error class. Confirm pending work remains visible, a known retry honors its budget, and an unknown result leads to readback or review. Inspect logs or audit context for correlation without raw credentials or payloads.

What to carry forward

Accept when known errors map to deliberate actions, unknown responses protect data and retry budgets, and recovery text remains specific. Keep coverage partial for unobserved intermediary behavior. Record the matrix, client revision, response fixtures, and any operation classes not yet exercised.

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