Aglet

Investigate asynchronous API bulk results

Investigation should follow one batch from acceptance to final record state. Use zero, partial, and complete fixtures with delayed status and expired-result variants. Compare the operation handle through every request, keeping duplicate submission, stale polling, and result loss as distinct hypotheses.

Build a useful investigation brief

  1. Build lifecycle fixtures

    Create batches with zero records, some records, all records, a delayed status, a failed item set, and an unavailable result. Record expected status, result count, and local state before execution. Keep record identifiers synthetic and stable.

  2. Trace handle and counts

    Capture submission response, operation handle, status requests, timestamps, completed and failed counts, result pages, and reconciliation writes. Compare every request’s handle and environment. Look for a status that advanced while result retrieval or local persistence lagged.

  3. Challenge completion meaning

    Vary polling interval, result retrieval timing, batch size, failure set, and process restart separately. Compare accepted, running, complete, partial, and expired states. If the API does not define one transition, record the missing documentation rather than infer completion.

What to carry forward

The investigation is ready when a lifecycle fixture shows the first mismatch between status, result, and local reconciliation. Deliver a bounded polling, retrieval, or reconciliation change. Keep retention and partial-completion limits explicit. Keep acceptance separate from completion.

Technical background: GitHub documentation.

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