How do you test a workflow that spans four services?

Been hitting the same wall for a while and curious how others handle it.

What's the failure shape?

Someone books a flight to London. Four things have to happen: confirm the booking, send a Slack message, fire a confirmation email, block the calendar. Travel is one vendor, messaging is another, email is another, calendar is another.

Spent way too long this week watching devs debug Paddle billing issues that never reproduced locally.

The pattern keeps repeating: subscription.activated arriving before subscription.created in prod, about 30% of the time. Handlers look clean, pass unit tests, handle retries correctly. But they assume events arrive in order. Paddle's sandbox just doesn't reproduce that chaos.

The gap most auto-fix tools have

They tell you the bug is fixed. They don't show you. Our rule has always been: make the bug happen on real code, apply the fix, show it stops happening. The gap was we could only do that for bugs we'd scripted in advance. Anything unusual and the honest answer was "found it, fixed it, can't prove this one."

What we built

We taught FetchSandbox to write the reproduction itself, no pre-scripted test required.

Most AI tools, when they're unsure, guess confidently.

That's how you burn an hour chasing the wrong bug.

We went the other way. Point ours at your repo and say what's breaking "customers are getting charged twice." Instead of guessing which API, it reads your code:

• Sees you have both Stripe and Paddle installed.

• Reads both webhook handlers your Paddle one has no idempotency check (line 16); Stripe dedupes fine.

• Tells you: "it's your Paddle handler." A fact from your code, not a hunch.

247 upvotes, 34 comments, finished second on a Sunday. The July launch got 362 and finished third. Better rank, smaller day. Both true.

The comments were worth more than the votes. A few things I didn't have good answers for, which is more useful than an upvote.

since the last launch, the goal was one thing: make FetchSandbox something you can actually gate a release on. not "looks tested" but provably tested.

what changed:

I audited an AI-written billing service this week. 22 findings, 10 critical.

None of them crashed. All returned 200. Four that stuck with me: an auth check that silently lets anyone in when one env var is missing, SQL injection in the one query that wasn't parameterized, a broken permission boundary so anyone can attach a charge to a workspace that isn't theirs, and a Stripe retry that double-grants seats because there's no idempotency check anywhere.

i build dev tools solo and use claude/cursor daily for API integration work. the pattern i keep seeing: agent finds a bug, fixes the code, declares done. what it does not do is rerun the exact failure scenario and prove the fix holds. that verification step was always on me.
we just shipped something in FetchSandbox to close that loop. after it catches a bug, it now nudges the agent to rerun the same request and surface a behavioral comparison, before vs after. same scenario, does it pass clean? that receipt is now automatic.
my rule: finding the bug is table stakes. proof that the behavior changed is the job. "i fixed the code" and "the fix works" are not the same claim.
curious how others handle this. do your agents ever rerun failure scenarios to verify, or does that step still fall back to you?

Last launch ended with 91 comments. I answered every one, and in most of them I said "not yet, that's next."

Six weeks on, here's what actually happened.

Done: @maschiojv asked about Paddle, it now has 21 curated failure patterns instead of a bare spec import.