Aglet

Investigate a changing API error response

Investigation should show why the same failure now selects a different client action. Pair a known error with the changed response, then follow both through decoding and retry policy. Keep a proxy-generated body, new server code, parser regression, and changed status semantics as separate hypotheses.

Build a useful investigation brief

  1. Build response fixtures

    Create safe fixtures for validation, authorization, rate, server fault, empty body, malformed body, and the newly observed response. Record expected client action for each before running them. Keep operation identity and whether the request was a read or write explicit.

  2. Trace decoder decisions

    Follow raw status and bytes through content negotiation, parser, typed error mapping, retry policy, and visible recovery. Compare the first field or branch that differs. Capture client and intermediary revisions so a changed response is not confused with a middleware transformation.

  3. Test the competing meaning

    Change one status, media type, body field, or intermediary condition at a time. Confirm whether the client preserves unknown detail without retrying blindly. If the response still supports multiple meanings, document the missing contract source instead of choosing one from a single sample.

What to carry forward

The investigation is ready when fixtures reproduce the response class, decoder divergence, selected retry branch, and operation consequence. Recommend the smallest safe decoder or evidence change. Keep unknown semantics visible where the available response cannot establish meaning.

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