Dheeraj S

For me it's when it forgets everything I told it 10 minutes ago...

I explain the repo.

It says "got it".

Then it rewrites the same file twice hehe

When a customer hits cancel, most workflows park at an approval step. The question nobody asks: has anything already been cancelled by then?

We ran a rehearsal on our synthetic Acme demo, wiring FetchSandbox (fetchsandbox.com/mcp) across Stripe, Zendesk, Square, and Slack twins. Three boundaries we actually checked: nothing fires while parked at approval, rejected approval leaves the subscription unchanged, and the workflow survives an app restart while parked then cancels exactly once after approval. 27/27 passed on October 18.

Scope caveat: synthetic provider twins, not live traffic. But that's the point, catching a premature cancellation in rehearsal is cheaper than finding it after a real customer emails you.

AI-assisted code moves fast enough that these intermediate states are genuinely easy to miss. You end up testing the happy path and calling it done.

I m building MELRA, a local runtime for MCP and CLI tools, and I m testing this recovery edge case: a write may reach the provider even though the agent never gets a response. Retrying can duplicate it, but waiting without a way to reconcile is frustrating. In the current alpha, MELRA parks that attempt until state can be checked. What evidence would you trust before allowing a retry, especially when provider lookups are slow?