Give each business operation a stable key
Choose operation identities that survive retries and restarts while still allowing legitimate second refunds or follow-up emails.
An operation key should identify the intended business operation, not the network attempt or agent session. Generate it when your application accepts the task and persist it before invoking a consequential action.
For Anlyon governed effects, the same operation key and same request return the existing operation. Reusing the key with a different request is refused with OPERATION_KEY_REUSE. Different keys can still represent duplicate business intent, so key design remains an application responsibility.
Choose the right level of identity
| Candidate | Problem or useful property |
|---|---|
| Current timestamp | Every retry looks like a new operation |
| Agent session ID | A restart changes the identity |
| Order ID alone | May prevent legitimate separate partial refunds |
| Persisted refund-request ID | Identifies one refund decision across attempts |
| Persisted outbound-message ID | Identifies one intended email across workers |
A business identifier need not expose customer information. Use an opaque durable ID and keep its meaning in your own database. Include an operation type when different actions share the same upstream identifier convention.
Decide what an edit means
If an operator changes the amount before dispatch, do not quietly reuse the key with changed input. Inspect the existing operation and follow an explicit replacement workflow. If the original may have run, reconcile it before accepting another business operation.
If the user intentionally requests a second partial refund, create a separate persisted request with its own review and allowance consumption. Deduplication should not make legitimate repeated business work impossible.
Test the application contract
Test duplicate delivery of the same task, a worker restart after submission, concurrent workers, and the same key with changed input. Assert that your application reuses the stored operation ID. Also test the intended second operation so your key is not too broad.
Operation identity does not replace provider idempotency or a shared impact limit. It also does not establish the outcome after a lost response. Those mechanisms solve different failures.
Use governed operation identity, idempotency fundamentals and restart recovery.