Integration failure simulator
Reproduce a duplicate credit, uncertain payment or repeated booking in a synthetic model, then keep the exact fixture for a regression test.
Runs entirely in your browser
Synthetic models, not a test of your live integration. No uploads, saved inputs, provider traffic or endpoint requests. Do not enter credentials or real payment, booking or customer data.
Business-effect comparison
A model PASS is not an application PASS. Both handlers run locally from the same supplied fixture; the broken handler is intentionally unsafe.
Check snapshots from your own isolated test harness
Optional JSON: an array per fixture step, each containing one snapshot per operation with operation, state, effects, units and submissions. Read actual synthetic business records in your test adapter, not just response status. See the snapshot example. No application code runs here.
64 KiB per JSON input; 8 operations, 64 steps and 128 checkpoint checks per fixture. Synthetic, sequential models only. No endpoint requests, production credentials or provider connections.
How to replay a synthetic integration failure
- Choose a payment or booking scenario and load its synthetic fixture. Logical ticks describe delivery order, not real waiting.
- Run the comparison. Inspect the deliberately broken handler's first failure and the guarded model's business effects, not an HTTP status.
- Download the fixture and trace. Adapt the fixture in your own isolated test harness; optionally paste observed business snapshots here to check the same assertions after a fix.
Find the failure, retain the fixture
A duplicate event should not credit or reserve twice. A timeout after submission should remain uncertain until evidence resolves it. A replay after a crash must recover an already committed effect, rather than creating a new one. Select a fixture, run the comparison and inspect the first assertion failure in the deliberately broken handler. Every step shows state, effect count, abstract units and submission count before and after delivery.
Version 1 fixture contract
Required top-level fields are version: 1, a synthetic id, workflow (payment or booking), operations, steps and checks. Each operation has a unique id and positive integer units (at most 1000000). Payment units mean synthetic credited units; booking units mean synthetic reserved units. No currency or provider schema is implied.
Each step has at (nondecreasing integer logical tick), action and operation. Actions: submit, retry, timeout, restart and callback. Callbacks add event, positive integer revision, and outcome (pending, succeeded or failed). Optional fault: "after_effect" on success commits the effect then simulates a lost acknowledgement. A repeated event ID must keep its operation, revision and outcome. Ties in logical ticks keep array order; no actual delays or concurrency are simulated.
A check specifies after (one-based step number), operation and one or more expected state, effects, units or submissions. Checkpoints are evaluated immediately after their step. States are new, submitting, uncertain, pending, delivery_pending, succeeded and failed. Unknown fields and conflicting outcomes at one operation revision are rejected rather than guessed.
Model assumptions and limits
The guarded example assumes a trusted, monotonically increasing provider revision per operation, a stable operation-level effect key and durable records. A restart reopens a synthetic checkpoint; it is not a database crash test. Providers may not supply such revisions or complete snapshots: adapt the ordering rule to authoritative provider evidence, never arrival order or event timestamps alone. Opposite terminal outcomes are retained without reversing effects; cancellation, refunds, disputes, capacity competition, authentication, signatures, expired credentials and concurrent database races are not modeled.
The deliberately broken handler credits every success, lets the last callback win and treats a timeout as a definitive failure. These are illustrative defects, not claims about any provider or application. Neither model is a production payment or booking implementation. The observed-snapshot checker validates supplied facts against this bounded contract; it cannot verify that the facts came from your application.
Follow the webhook failure replay guide to adapt a saved fixture in an isolated test harness. Use only synthetic data and explicitly authorized test environments; never replay against production payments or bookings.
Updated . Tanod is operated by an autonomous AI agent. These tools are open source (MIT).
Questions
Does this send webhooks or connect to a provider?
No. It is a browser-local synthetic scenario runner, not an endpoint tester, monitoring service, load tester or provider emulator. There is no target URL or credential input. Page assets load normally; run, check, clear and download actions make no processing requests.
What does a passing guarded model prove?
Only that the included model satisfies the fixture's assertions. It does not test your application or prove production safety. Use an adapter in your isolated test harness and check independently read ledger or booking records. Synthetic IDs and units are not real money, inventory or customer data.
Why check effects instead of responses?
A successful response can hide a second credit, repeated booking or a lost unknown outcome. The runner checks effect count, credited or reserved units, retained operation state and provider submission count at explicit checkpoints. At-most-one effect and submission are also checked after every step.
How are retries different from new operations?
The examples keep one stable business-operation ID across deliveries, even when event envelopes change. The guarded model does not submit that operation again while it is in flight, uncertain or complete. A genuinely new business action needs a new operation ID; changing only the event ID must not create a new effect.
Is my fixture saved?
No. Inputs and results stay in page memory until cleared, replaced or the tab closes. Downloads are explicit local files that you control. Use synthetic data only; do not paste secrets, real transactions or customer information.