Idempotency
Every mutation carries an Idempotency-Key, scoped by client binding, workspace and operation. The transaction stores the exact response before success is sent. A retry with the same key and the same canonical input replays that stored response without running the mutation again.
Reuse outcomes
Section titled “Reuse outcomes”| Retry | Result |
|---|---|
| Same key, same canonical input | Stored response replayed byte for byte, same status. No duplicate task, lease, message, event or outbox job. |
| Same key, different input | 409 IDEMPOTENCY_MISMATCH. Use a fresh key for a different intent. |
| Unknown key | First attempt; runs normally. |
The canonical hash covers the parsed operation inputs (stable field order, no insignificant whitespace, SHA-256), so key order and spacing never change the result.
A timeout means the outcome is unknown
Section titled “A timeout means the outcome is unknown”A timed-out client receives no grant. Retry the same operation with the same key to retrieve the recorded result. Never invent a second operation just to retry. Until then the outcome is unknown (503 OUTCOME_UNKNOWN where a verdict is required).
Retention
Section titled “Retention”Records are kept for at least 7 days. Outside the supported retry window, reconcile state explicitly.
If the daemon crashes between commit and reply, it replays the stored result on retry.