Agent-readable docs index: /site/docs/llms.txt. Full docs in one file: /site/docs/llms-full.txt. Download /site/docs/docs.zip to grep all markdown files locally.
AgentTwin 0.2.2 · discovery and hosted workflow execution · Node.js 22.12+

Example: timeout after a write

This historical refund example illustrates a fault class, not AgentTwin’s scope or a shipped Stripe adapter. Hosted custom-collection workflows can test committed-write delays and retries. Stripe fidelity and provider-native conformance remain unimplemented.
One useful fault class is: a service completes a write, but the caller times out before receiving the response. The caller retries, and the action happens twice.

The scenario

A worker asks a payment provider to create a refund. The provider commits the write, but the response times out. The worker cannot tell whether the refund happened and retries. A weak implementation creates a second refund. A resilient implementation uses an idempotency key and verifies final state.
Rendering diagram...

What the scenario declares

Starting stateOne eligible payment, zero refunds.
Injected conditionCommit refund; discard response; allow retry.
Expected outcomeExactly one refund record, one customer notification, a recoverable trace.
Regression artifactVersioned starting state, fault point, input, and assertions.

Why this wedge

  • Real — this failure class appears in production integrations, not only in theory.
  • Costly — a duplicate refund moves money and damages trust.
  • Hard to reproduce — it needs a write that commits and a response that never arrives.
  • Testable without risk — a developer should be able to reproduce it without credentials, network calls, or a real account.
The current browser demo shows this behavior through fixtures. No provider parity has been established yet, and no connector or runner exists in this repository.