Aglet

Verify per-event handling for webhook batches

Verification must prove both capacity boundaries and partial-completion behavior. Run one event, a normal batch, a boundary-sized batch, an oversized batch, mixed validity, interruption, and retry. Inspect event-level receipts and effects, not only aggregate response or request duration. Use a known receiver revision. Record the configured limit.

Check whether the outcome improved

  1. Define batch outcomes

    Write expected response, envelope disposition, per-event receipt, parser result, processing state, effect count, and replay treatment for each batch fixture. State whether an unsupported size is rejected, split, or held for review.

  2. Exercise partial completion

    Run mixed and interrupted batches, then compare every event identity with durable receipt and downstream state. Confirm a malformed event does not erase valid neighbors and a retry cannot repeat an already committed event.

  3. Check the recovery edge

    Repeat near-limit and over-limit cases after receiver restart or configuration change where safe. Verify incomplete events remain visible and can be reconciled without assuming the aggregate acknowledgement describes each event.

What to carry forward

Accept when supported batch sizes preserve event identities, partial outcomes remain visible, and retries cannot create unexplained duplicate effects. Keep verification open for unobserved sender batching rules. Record size matrix, receiver revision, recovery result, and remaining uncertainty. Record per-event counts.

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