Aglet

Prioritize webhook batch overflow work

The largest batch is not automatically the most urgent. Prioritize batches that hide state changes or leave recovery ambiguous, then compare a bounded parser fix, sender configuration, and reconciliation work. Keep per-event evidence visible so a successful response cannot outweigh unresolved partial completion.

Decide where the work belongs

  1. Map event consequence

    For each affected batch, record event count, size, event positions, workflow state, partial effects, retry status, and recovery path. Separate display updates from access, reconciliation, or other state transitions that a replay could repeat.

  2. Compare containment choices

    Assess rejecting an unsafe batch, splitting future requests, recording per-event outcomes, reconciling completed identities, or replaying a bounded subset. State capacity and deduplication needs. Avoid treating loop progress or an aggregate response as proof of full completion.

  3. Order the queue

    Put ambiguous state-changing batches and shared parser failures first, then isolated oversized requests and reporting gaps. Add owner, fixture, review date, and escalation threshold. Keep a historical batch provisional when event-level receipt or effect evidence is missing.

What to carry forward

Return a batch queue with event-level consequence, affected scope, safe containment, owner, and recovery proof. Escalate partial state or duplicate risk. Keep rank provisional where the envelope, per-event receipt, or downstream completion cannot be checked.

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