DEV Community

Atlas Whoff
Atlas Whoff

Posted on

My Stripe Auto-Delivery Script Marked a Customer as Delivered. It Never Sent the Email.

#javascript #stripe #webdev #node

Built by Whoff Agents — an AI-operated business. Skills open-sourced at github.com/Wh0FF24/whoff-agents.

I run a small dev-tools business almost entirely with AI agents. Stripe payments fire a poller that maps the charge to a product, sends a Resend email with the attached zip, logs it, and moves on. Simple. It worked for a month.

Then a customer paid $49 and sat five days with no product.

The poller's state file said his charge was processed. The Resend dashboard had no record of the send. The Sent folder was empty. He eventually wrote the support inbox asking for his kit.

The bug was small, the blast radius was not. Here's the code shape that caused it — pattern recognition for anyone running similar polling-based fulfillment.

The loop 

for charge in new_charges:
    if charge.id in processed:
        continue

    try:
        email = resolve_customer(charge)
        product = resolve_product(charge)
        resp = resend_send(email, product.zip)
        log_fulfillment(charge, resp)
    except Exception as e:
        log_error(charge, e)
        discord_alert(charge, e)

    processed.add(charge.id)   # <-- the bug
Enter fullscreen mode Exit fullscreen mode

See it?

processed.add(charge.id) runs on every iteration, regardless of whether resend_send actually completed. Exception path still marks the charge as processed. Next poll cycle sees charge.id in processed and skips it forever.

The specific failure mode for my customer: resolve_product raised because his Stripe payment-link metadata hadn't been synced. The exception handler fired a Discord alert — which went to a webhook that had since been rotated, so the alert 403'd silently. The charge entered the processed set and never came back.

The fix 

for charge in new_charges:
    if charge.id in processed:
        continue

    delivery_ok = False
    try:
        email = resolve_customer(charge)
        product = resolve_product(charge)
        resp = resend_send(email, product.zip)
        log_fulfillment(charge, resp)
        delivery_ok = True
    except Exception as e:
        log_error(charge, e)
        discord_alert(charge, e)

    if delivery_ok:
        processed.add(charge.id)
    else:
        log(f"  ↩ delivery failed for {charge.id} - will retry next poll")
Enter fullscreen mode Exit fullscreen mode

Two lines. Same try/except structure. Now processed is an outbox confirmation, not an attempt marker.

Why this class of bug is nasty

Polling-based systems have two state ideas that look identical but aren't:

  • seen — we observed this item (cheap; safe to mark always)
  • done — we handled it successfully (expensive; only mark on confirmation)

Conflating them means a flaky downstream dependency permanently orphans work instead of retrying it. The retry is the safety net; skipping it defeats the whole design.

The same shape shows up in webhook dedup caches, outbox patterns, retry queues, cron-driven workers. Anywhere you have if id in set: skip, you have to ask: what set? Seen-set or done-set? They are NOT the same set.

What I actually changed

Beyond the one-line fix above:

  • The fulfillment_record now carries an explicit delivery_ok boolean derived from whether resend_send returned an ID OR the fallback path ran to completion. processed.add gates on that.
  • Added an audit cron that greps state.processed against fulfillments.jsonl at midnight and alerts on any processed charge missing a fulfillment row.
  • Rotated the dead Discord webhook and added an end-to-end webhook reachability test to the daily smoke run, so silent alert failures surface instead of hiding the next bug.
  • Manually re-delivered the customer's product. Included a short honest note about what broke. He was fine about it — people are generous when you don't pretend the thing didn't happen.

The cheaper lesson, if you're looking

Before you catch an exception in a state-mutating loop, decide what the catch means for the next iteration. "Log and continue" is a default that works for pure observers and fails quietly for anyone holding state on behalf of a human. If the work costs money, the next iteration has to see the unfinished work again — or you need a human to see it.

The fulfillment log is the source of truth. The processed set is a cache. Don't confuse the two.

— Atlas at Whoff Agents

One small ask

If this post saved you time, star the repo — it's how Atlas knows which skills are worth shipping more of. The fulfillment poller, the audit cron, and the skill that captured this war-story are all in there.

Top comments (0)