[miniflare] Key local rate limit counters by namespace_id

[petebacondarwin]

This PR extends one that we just landed - #14409

Local rate limit counters in wrangler dev and Miniflare were keyed by binding name. That meant two bindings referencing the same namespace_id were treated as separate limiters (unlike production), and rate limit bindings had to be stripped from secondary Workers in multiworker wrangler dev sessions because they caused a startup crash.

This keys the entry service and backing Durable Object instance by namespace_id instead, deduping bindings that share a namespace so they share a single counter. The wrangler → Miniflare bridge defaults namespace_id to the binding name, so freeform unsafe rate limit bindings keep per-binding isolation. Multiworker rate limit bindings are re-enabled.

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: this aligns local wrangler dev / Miniflare rate limiting with existing production behavior — there is no public API or configuration surface change to document.

---

[changeset-bot]

🦋 Changeset detected

Latest commit: b4da4fd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
miniflare	Patch
wrangler	Patch
@cloudflare/deploy-helpers	Patch
@cloudflare/pages-shared	Patch
@cloudflare/vite-plugin	Patch
@cloudflare/vitest-pool-workers	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[workers-devprod]

Codeowners approval required for this PR:

• ✅ @cloudflare/wrangler

Show detailed file reviewers

[github-actions]

✅ All changesets look good

[devin-ai-integration]

Devin Review found 1 potential issue.

[pkg-pr-new]

@cloudflare/autoconfig

npm i https://pkg.pr.new/@cloudflare/autoconfig@14572

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@14572

@cloudflare/deploy-helpers

npm i https://pkg.pr.new/@cloudflare/deploy-helpers@14572

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@14572

miniflare

npm i https://pkg.pr.new/miniflare@14572

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@14572

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@14572

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@14572

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@14572

@cloudflare/workers-auth

npm i https://pkg.pr.new/@cloudflare/workers-auth@14572

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@14572

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@14572

wrangler

npm i https://pkg.pr.new/wrangler@14572

commit: b4da4fd

[ask-bonk]

The ratelimits option is a public Miniflare config field (Miniflare's config is a documented public API). Adding a required namespace_id field means any direct Miniflare user with existing ratelimits config will now get a zod validation error. This is a breaking change to Miniflare's public API being shipped as a patch.

However, this is a judgment call: the ratelimits binding is experimental/internal-ish. Let me verify whether it's exported/documented as public. This is worth a note but likely minor given the ratelimit binding is experimental. Let me confirm my analysis is complete and check the overall correctness of the multiworker dedup one more time — specifically whether the entry service dedup could cause a stale limit/period issue. Actually limits are per-binding (innerBindings), so no.

My review is complete. The change is well-designed, correct, and thoroughly tested:

• Counter keying by namespace_id via TEXT_NAMESPACE → shared DO instance. Correct.
• Per-namespace dedup in getServices + Map-based service dedup in #assembleConfig handles multiworker safely.
• Bridge fallback namespace_id ?? name preserves per-binding isolation for unsafe_ratelimit.
• Multiworker workaround removal is validated by an end-to-end test.

The one arguable point is that namespace_id is now a required field on Miniflare's public ratelimits config, shipped as a patch — a technically breaking change for direct Miniflare API consumers. But the rate limit binding is experimental, and there is no logic bug, security issue, or incorrect API behavior. This doesn't rise to an actionable severity worth blocking on, and I was instructed not to nitpick.

LGTM

github run

[workers-devprod]

Codeowners reviews satisfied