My 3-layer agent session locking fix stopped it from quietly wrecking customer records

说明与用途

通过实施三层防御（实体锁、幂等键和有序持久化），阻止了在代理工作流中重试和并行工具调用导致的外部系统数据损坏。

问题

Agent workflows that mutate external systems (HubSpot, Zendesk, etc.) can corrupt data when retries or parallel tool calls occur, even if a per-entity lock is used.

结果

The 3‑layer defense eliminated silent data corruption, ensuring that retries do not create duplicate external changes and that parallel tool calls do not overwrite each other.

工作流

• Acquire per‑entity advisory lock
• Generate idempotency key at workflow boundary
• Store idempotency key before external request
• Reserve mutation in PostgreSQL table
• Execute external mutation if not already attempted
• Persist state with version check
• Release lock

证据

I learned this the ugly way at 2:13 a.m. when an n8n workflow reopened a closed Zendesk ticket, reassigned the account owner in HubSpot, and then did both again when the webhook retried.

来源

If your agent can write to HubSpot, Zendesk, Salesforce, Stripe, or your own internal APIs, a lock alone is not enough.

来源

I split tools into two classes: read-only and mutating. Then I allowed concurrency only for read-only calls.

来源