agent's budget update failed with "DuplicateBudgetName" after a retry

TL;DR

The first update call actually succeeded, but the agent did not see the success (timeout, dropped response), so the retry tried to create the budget again and hit the duplicate-name error. Make the write idempotent: check whether the budget exists before creating, and use update calls for existing budgets. DuplicateBudgetName after a retry almost always means the first call worked.

Error

agent's budget update failed with "DuplicateBudgetName" after a retry

Steps

1. Check whether the budget actually exists and has the intended values. Expected: the budget exists with the first call's values, confirming the retry was unnecessary.
2. Change the agent to describe-budgets first: if the budget exists, update it; only create when it is absent. Expected: the create path never fires for existing budgets.
3. Add idempotency to the retry logic: retries of an update must be updates, never creates. Expected: retried calls converge instead of conflicting.
4. Verify the budget values match the intent after the fix. Expected: the budget reflects the desired thresholds and notifications.
5. Re-run the agent's budget sync. Expected: no DuplicateBudgetName errors; updates apply cleanly.

When to use

• A budget update fails with DuplicateBudgetName after a retry.
• The agent cannot tell create from update.
• Retry logic turns timeouts into duplicate errors.

When not to use

• The account hit the maximum number of budgets (a limit problem).
• Two different budgets genuinely need the same name (rename one).
• The budget does not exist and creation still fails.

Tool compatibility

AWS Budgets API (current 2026 releases). Applies to agents managing budgets.

Variant phrasings

"budget already exists" on retry

The first call succeeded. Check-then-act makes retries safe.

retry created a duplicate budget error

Separate the create path from the update path.

budget sync fails intermittently with duplicates

Timeouts hide successes. Describe before create.

Why it happens

Distributed calls fail ambiguously: a timeout can mean the request never ran or that it ran and the response was lost. Naive retry replays the create, and the second create collides with the first one's success. Check-then-act (describe first) plus update-instead-of-create on retry makes the operation idempotent, which is the standard answer to ambiguous failures.

Provenance

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