Idempotency Keys

Stable construction

Build keys from the business action and resource identity, not from a random timestamp. Good examples include refund:ledger-entry-id, customer-export:request-id, and payment:invoice-id:attempt-1. Bad keys include random UUIDs generated after every retry, because they create a new decision for the same business action.

Duplicate prevention

The key lets HaltState return the same decision for the same attempted action and lets the worker avoid duplicate execution. The ledger or business store should still enforce a uniqueness constraint, because policy idempotency and database idempotency solve related but different problems.

Approval resumes

When an action requires approval, a later retry should use the same key. That retry can discover that the approval was granted, rejected, expired, or still pending without creating a second approval request.

Construction examples

from datetime import date, datetime

op_key = f'nightly-cleanup-{date.today().isoformat()}'
op_key = f'delete-user-{user_id}'
op_key = f'deploy-{datetime.now().strftime("%Y%m%d_%H%M%S")}'
op_key = f'transfer-{sender_id}-{recipient_id}-{amount}-{date.today()}'
op_key = f'refund:{ledger_entry_id}'

Exit-and-retry pattern

from haltstate import HaltStateClient, ApprovalPending, ActionDenied
from datetime import date
import sys

client = HaltStateClient(tenant_id='acme', api_key='hs_xxx')
op_key = f'maintenance-{date.today().isoformat()}'

try:
    with client.guard('system.maintenance', params={}, idempotency_key=op_key):
        run_maintenance()
except ApprovalPending:
    print('Pending approval - will retry next cron run')
    sys.exit(0)
except ActionDenied as exc:
    print(f'Denied: {exc}')
    sys.exit(1)

Ledger idempotency

Policy idempotency and ledger idempotency are related but separate. HaltState should return the same decision for the same action key. The business ledger should still enforce a uniqueness constraint so a process crash or retry cannot write a second execution row for the same refund, payment, export, or message.

Implementation notes

Keep the HaltState call as close as possible to the side effect. The agent may plan and draft freely, but the wrapper around the actual action should be the place where authority is checked. That wrapper should send only the context required for policy evaluation: safe identifiers, normalized amounts, action names, risk flags, schedule windows, and redaction status. Raw customer payloads and secrets should stay in the business system or protected operator tooling.

Operational evidence

For each action, preserve the decision, the worker outcome, the idempotency key, safe resource references, latency, proof status, and redaction status. This evidence supports incident response and control narratives because it shows what the system did at runtime rather than only describing what the policy document intended. HaltState supports alignment work; it is not a substitute for legal advice or a compliance certification.