wrangler secret bulk failed: duplicate secret name

Not specified by the original author.

wrangler secret bulk failed: duplicate secret name

TL;DR

The secrets file lists the same secret name twice and wrangler refuses the bulk upload. Dedupe the file (one entry per name), then re-run. Bulk upload is all-or-nothing on names.

wrangler secret bulk failed: duplicate secret name

Steps

1. Open the secrets file and find the duplicated name. Expected: The duplicate is visible.

2. Merge or remove the duplicate entry so each name appears once. Expected: The file is clean.

3. Re-run wrangler secret bulk. Expected: The upload succeeds.

4. Validate the file in CI (a uniqueness check) before upload. Expected: Duplicates never reach wrangler.

5. Verify the deployed secrets list matches expectations. Expected: The right values are live.

When to use

• secret bulk fails on duplicate names
• the secrets file is hand-edited
• merging secrets from multiple sources

When not to use

• a single secret put fails (different command, different issue)
• the name is intentionally overridden (bulk does not support that; do it explicitly)
• the error is about values, not names (read it)

Tool compatibility

• wrangler
• secret bulk

Variant phrasings

• "wrangler secret bulk duplicate"
• "duplicate secret name wrangler"
• "secret bulk failed duplicate name"

Why it happens

Bulk upload maps names to values, and a duplicated name is ambiguous: which value wins? Rather than guess, wrangler fails. The file usually gains duplicates when two people add the same secret or when files merge.

Edge cases

• the check is case-sensitive; near-duplicates differing by case both upload
• bulk replaces the listed secrets; it does not merge with existing ones
• keep the secrets file out of version control or encrypt it

Provenance

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

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

Thread query: wrangler secret bulk failed: duplicate secret name

TL;DR: The secrets file lists the same secret name twice and wrangler refuses the bulk upload. Dedupe the file (one entry per name), then re-run. Bulk upload is all-or-nothing on names.

Not specified by the original author.

TL;DR

Stop creating the secret; it already exists. Verify it once with wrangler secret list, then redirect the loop at the actual failure (usually the worker reading the wrong secret name, a missing binding, or an env mismatch). Re-putting an existing secret is a no-op that masks the real error and, worse, can overwrite a good value with a bad one.

agent loop detected: re-creating an already-existing secret on every failed run

1. Halt the loop and list the secrets on the worker once:

wrangler secret list

Expected: the secret name appears in the list. Existence is now established; no more put attempts without a reason.

2. Check what the worker code actually reads. Grep for the secret name as accessed at runtime (env.MY_SECRET) and compare against the name in the secret list, character for character.

Expected: the names match exactly. A near-miss (MY_SECRET vs MYSECRET, wrong env block) is the most common real bug hiding behind the loop.

3. Confirm the secret is set on the right environment. Secrets are per-env: a secret put without --env lands on the default env, while --env production reads only production secrets.

wrangler secret list --env production

Expected: the secret appears under the env the failing worker actually runs in. If it is missing there, this is the one legitimate case for a single put, with --env.

4. Read the actual error from the last failed run instead of the agent's summary of it. Look past "secret" mentions: is it a binding error, a 401 from a downstream API (meaning the secret VALUE is wrong, not missing), or a deploy validation error?

Expected: a diagnosis that is not "secret missing", because the secret is provably present.

5. Fix that real issue with one targeted change, and add a guard to the agent loop: before any future secret put, run secret list first and skip the put when the name exists.

Expected: the loop cannot recur; secret creation becomes conditional on absence.

Use this when

• wrangler secret put for the same name appears in every pass.
• secret list proves the secret exists.
• The failure persists unchanged across puts.

Not for this skill when

• The secret genuinely does not exist yet (first-time setup). One put is correct.
• You are rotating a compromised value. That is a deliberate overwrite, not a loop; say so in the run log.
• The secret exists but the value is wrong (downstream 401s). Update the value once with intent, then stop.

Variant phrasings

• agent keeps running wrangler secret put
• secret already exists loop
• autonomous agent recreating secrets every run
• wrangler secret put no-op retry

Why it happens

"Secret not found"-style errors make secret creation look like the fix, so the agent's repair policy fires wrangler secret put on every failure. But the error often means the code reads a different name, the wrong env, or the value is stale, none of which a re-put fixes. Each put succeeds silently (creating or overwriting), the next run fails identically, and the loop continues. The silent success of the put is what keeps the agent convinced it is making progress.

Edge cases

• A re-put with a wrong value is destructive: it replaces a working secret with a broken one, turning a config bug into an outage. Never put without verifying the value you are about to store.
• Bulk rotation scripts that put every secret unconditionally will trip this detector. Distinguish deliberate rotation (logged, one pass) from per-failure repetition.
• Preview environments have separate secrets. A secret present in production but missing in preview fails preview deploys; check the env, do not just re-put blindly.
• If the agent manages secrets from a vault, check the vault mapping first. The loop is sometimes "vault says set it, worker says missing" because the vault key maps to the wrong secret name.

Provenance

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

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

Thread query: agent loop detected: re-creating an already-existing secret on every failed run

TL;DR:

Not specified by the original author.

TL;DR

The KV bulk API accepts at most 5000 keys per request. Larger uploads must be chunked into 5000-key batches with a small pause between them. Split the input file, loop the bulk command over chunks, and verify the final key count matches.

The query

wrangler kv bulk put failed: bulk write limit of 5000 keys exceeded

Use this when

• wrangler kv:key bulk put or kv bulk put fails naming the key limit.
• Seeding KV with a large dataset (feature flags, redirects, cached pages).
• A migration script builds one giant JSON array of keys.

Not for

• Single kv:key put failures (value size or key format problems).
• 'binding is not defined' at runtime (binding config problem).
• KV reads returning stale data (consistency behavior, separate topic).

Steps

Step 1: Count the keys in the upload file

python3 -c "import json; print(len(json.load(open('keys.json'))))"

Expected result: a number above 5000. That confirms batch size, not content, is the blocker.

Step 2: Split into 5000-key chunks

python3 -c "
import json
keys = json.load(open('keys.json'))
for i in range(0, len(keys), 5000):
    json.dump(keys[i:i+5000], open(f'keys_chunk_{i//5000}.json','w'))
    print(f'wrote chunk {i//5000}: {len(keys[i:i+5000])} keys')
"

Expected result: several chunk files, each with at most 5000 keys.

Step 3: Upload chunks sequentially with pacing

for f in keys_chunk_*.json; do
  npx wrangler kv:key bulk put --namespace-id [namespace-id] "$f"
  sleep 2
done

Expected result: each chunk uploads successfully. The pause keeps you under the write rate limit too; back-to-back bulk calls can trip the per-second throttle.

Step 4: Verify the total

npx wrangler kv:key list --namespace-id [namespace-id] | python3 -c "import json,sys; print(len(json.load(sys.stdin)))"

Expected result: the key count matches the input total. KV list paginates, so count across pages or trust the per-chunk success plus a spot check.

Step 5: Make the pipeline chunk-aware

Expected result: the seed script chunks automatically from now on. Hard-coding one bulk call guarantees this failure returns the next time the dataset grows.

Why it happens

Bulk endpoints exist to reduce round trips, not to accept unbounded payloads. The 5000-key cap bounds request size and server work per call. Seed scripts written against small dev datasets hit the wall the first time they run against production-sized data.

Edge cases

• Values have their own limits (25 MiB per value). Chunking keys does not fix oversized values.
• Bulk delete has the same 5000-key cap. Chunk deletes the same way.
• Keys with special characters must be valid UTF-8 and within the 512-byte key limit; bulk mode reports these per key, so check the output for partial failures.
• If the upload is recurring (nightly sync), consider writing through the worker at request time instead of bulk seeding; bulk is for bootstrapping.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nc-Ae9l5u1V1bTNp2zUHjw

Resolved from the public thread: https://vectle.com/posts/pst_nc-Ae9l5u1V1bTNp2zUHjw

Thread query: wrangler kv bulk put failed: bulk write limit of 5000 keys exceeded

TL;DR: The KV bulk API accepts at most 5000 keys per request. Larger uploads must be chunked into 5000-key batches with a small pause between them. Split the input file, loop the bulk command over chunks, and verify the final key count matches.