agent infinite loop recreating trial workspace idempotency key collision

Break the agent's infinite loop recreating a trial workspace on an idempotency key collision

TL;DR

The agent retries a create with the same idempotency key, the API returns the conflict instead of the workspace, the agent reads the conflict as "not created yet" and retries again. Fix it by deriving the key from the workspace identity plus the action, checking whether the workspace already exists before creating, and capping retries with a circuit breaker.

The problem

attempt 1: create workspace, key [your value] then 201 created
attempt 2 (retry, agent missed the 201): create workspace, key [your value] then 409 key already used
agent: "creation failed, retrying" then attempt 3, 4, 5 ... forever
actual state: one workspace exists, agent keeps "creating" it

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent infinite loop recreating trial workspace idempotency key collision"

Fix it

Step 1: Check existence before creating

Before any create call, look up the workspace by its natural identity (account id, slug, or name). If it exists, adopt it and move on - the create step is already done.

Expected: the agent never attempts a create for something that already exists.

Step 2: Derive the key from workspace identity plus action

Build the idempotency key from stable values: workspace slug plus the action name plus the run id. Never reuse a bare static key across attempts that mean different things.

Expected: each logical operation has a unique key, and genuine retries of the same operation share it correctly.

Step 3: Read the 409 as "already done," not "failed"

When the API returns a key-conflict or already-exists response, treat it as success-with-existing-resource: fetch the existing workspace and continue. A 409 on a create-with-key is information, not an error.

Expected: the loop's fuel - misreading 409 as failure - is gone.

Step 4: Cap retries with a circuit breaker

Allow at most 3 create attempts per workspace, then fail the step loudly with the full attempt history. No unbounded retry loops, ever.

Expected: even a misconfigured key cannot loop forever; it fails fast and visibly.

Step 5: Prove it with a forced collision in staging

Create the workspace, then run the agent's create step again with the same key.

Expected: the agent detects the existing workspace on the first check and completes the step without a second create call.

When this applies

• Workspace or account creation repeats endlessly in the logs
• Each attempt reuses the same idempotency key and gets a conflict
• The resource actually exists while the agent believes it does not

When it doesn't

• The create genuinely fails each time (fix the underlying create error)
• No idempotency key is used at all (add one, then apply this skill)
• The loop is on a different step (find that step's misread signal)

Compatibility

Stripe, Auth0, and any API with idempotency-key support; trial workspace, tenant, and account provisioning flows.

Variant phrasings

agent keeps creating duplicate workspaces on retry

Same fix. The existence check in Step 1 is the primary defense; the key hygiene is the backup.

idempotency key already used error looping

Read the error as the answer it is: the operation already happened. Fetch the result instead of repeating the request.

Why it happens

Idempotency keys are supposed to make retries safe, but they only work if the agent understands the conflict response. This agent was taught "retry on failure" and never taught that a key collision means the work is done. So it retries the request that already succeeded, gets the exact conflict that proves it succeeded, and reads the conflict as a reason to retry. The loop is a misunderstanding with a while-true around it.

Edge cases

• Keys that include timestamps: every retry gets a new key and the API cannot dedupe; use stable keys
• Partial creation (workspace created, setup incomplete): the existence check must verify setup state, not just existence

If it still fails

• Capture the key values, the attempt log, and the API responses before changing anything else.
• Reproduce with a single test workspace so you are not debugging a crowd.

Prevention

• Every create the agent performs gets an existence check first and a stable key second.
• 409-on-create handling is tested for every provisioning flow before launch.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wmO6YfY66uQC7tahiBbq5g