Aglet

Learn from partial API response failures

The durable lesson is a completeness contract that names which bytes, counts, cursors, and required fields make a response authoritative. Preserve the cut point and the state change that exposed the failure. Record server or proxy limits separately from local parser behavior.

Keep the lesson for the next incident

  1. Document completeness rules

    Record required metadata, collection counts, continuation behavior, nested fields, response-size assumptions, and the local state for incomplete data. Define when a result may replace known-good state and which cases need re-read or review.

  2. Keep cut-response fixtures

    Retain full, cut, missing-marker, partial-contract, and large-response examples with synthetic identifiers. Store expected completeness and persistence state. Include the original truncation shape so transport or decoder changes have a clear comparison.

  3. Review incomplete-result signals

    Watch parser warnings, size anomalies, missing continuation, incomplete flags, and replacements of complete data. Assign an owner and threshold for investigation. Close the follow-up only when relevant endpoints and response sizes exercise the contract.

What to carry forward

Close learning with completeness rules, redacted fixtures, parser and transport owners, and recurrence signals. Keep external limits visible. The useful outcome is an unmistakable incomplete state and safer recovery path, not a promise that every response will arrive whole. Keep the incomplete state easy to find.

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