ClawGuard Crash-Safety Triage — evidence page
What happens when a side effect commits and the acknowledgement never comes back
This page shows the failure case we test, the evidence structure used in delivery, and the boundary of what the current evidence can prove.
The failure case
Here is the sequence we test:
effect commits → response disappears → worker dies → job returns → baseline duplicates → hardened path skips duplicate
Demo receipt data: same trigger, two outcomes
- business_key
- order:42
- request_hash
- a6e66447e7f0b739cb2e9…e3fad80
- effect_ids
- effect-1 effect-2
- execution_ids
- exec-baseline-1, exec-baseline-2
- worker killed
after commit - true
- business_key
- order:42
- request_hash
- a6e66447e7f0b739cb2e9…e3fad80
- effect_ids
- effect-1
- execution_ids
- exec-hardened-1, exec-hardened-2
- worker killed
after commit - true
business_key (order:42),
the same request_hash, and the same crash point. The only
difference between the two columns is whether the idempotency path was
enabled. Source: artifacts/demo-receipt.json in the ClawGuard
Failure Lab.
What a duplicate effect means in plain terms
A "duplicate effect" means the same business event produced two durable, external effects instead of one. What that costs depends on what the side effect actually is:
- Charge — the customer is billed twice for one order.
- Email — the customer (or a colleague) gets the same notification, receipt, or alert twice.
- Provisioning — an account, seat, or resource gets created or granted twice.
- Record mutation — a CRM field, ticket, or database row gets updated or incremented twice.
None of this requires a "hack" or an attacker. It only requires a worker to die after a side effect commits but before the workflow gets to acknowledge it — a normal crash, not an exotic one.
What this evidence proves — and its boundary
The demo receipt shows the evidence shape and the baseline-versus- hardened difference for one simulated business key under one simulated crash window. It does not, by itself, tell us how a real n8n deployment behaves.
Directly from the lab's own claim boundary (LIVE_GATE.md):
A live result proves only the selected workflow, selected side-effect path, selected n8n version/configuration and selected fault window. It does not prove universal exactly-once semantics.
The live gate is defined, with real stop conditions
We have not run a live n8n capture. Docker Desktop was unavailable when this evidence was built. What we do have is a written live-gate procedure with stop conditions. It refuses to call a result PASS unless the evidence supports it:
- No kill after a confirmed effect commit → no duplicate claim.
- No durable readback →
UNRESOLVED, not PASS. - Any real external credential or customer system appears → stop and remove it from the lab.
Current lab status