Aglet

Triage a webhook batch event overflow

A batch may fail because of byte limits, event count, parser memory, or partial completion followed by retry. Select one bounded request and account for every event from the envelope through the final disposition. Separate transport rejection, truncation, processing failure, and duplicate replay before proposing a larger limit.

Establish what is happening

  1. Freeze one batch

    Record endpoint, environment, content length, event count, envelope markers, batch identity, and each safe event identifier. Note which events were accepted, rejected, absent, or unknown. Keep payload values out of the evidence unless a field is necessary to reproduce parsing.

  2. Find the first incomplete boundary

    Compare request receipt, size and count validation, envelope parsing, per-event loop, durable receipt, response, and downstream state. Distinguish a request rejected before parsing from a batch acknowledged after only some events completed.

  3. Bound the affected work

    Group examples by endpoint, batch size, count, receiver revision, event position, and disposition. Separate one bad event from a parser limit and a sender retry of partially applied work. Preserve event identity for any recovery review.

What to carry forward

Triage is complete when one batch has a reproducible trigger, a named first incomplete boundary, affected event scope, and explicit unknowns. Hold blanket size increases. Route parser, per-event receipt, transport, and replay questions to separate owners.

Technical background: Stripe 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