cloudflare/workers-sdk miniflare@5.20260801.0-alpha

on GitHub

Patch Changes

• #14984 9c74538 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  @cloudflare/workers-types	^5.20260730.1	^5.20260731.1
  workerd	1.20260730.1	1.20260731.1

• #15012 0d33cb8 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  @cloudflare/workers-types	^5.20260731.1	^5.20260801.1
  workerd	1.20260731.1	1.20260801.1

• #14968 a88d169 Thanks @petebacondarwin! - Fix local rate limiting being disabled entirely when bindings share a namespace_id but use different periods

  The emulated Ratelimit binding tracked one counter per key per namespace, ignoring the period. Two bindings pointing at the same namespace_id with different simple.period values therefore overwrote each other's counter on every call — each one seeing a window it did not recognise, and so resetting the count to zero — with the result that neither binding ever limited anything:

  {
    "ratelimits": [
      {
        "name": "BURST",
        "namespace_id": "1001",
        "simple": { "limit": 20, "period": 10 }
      },
      {
        "name": "SUSTAINED",
        "namespace_id": "1001",
        "simple": { "limit": 50, "period": 60 }
      }
    ]
  }

  Counters are now tracked per period, matching production, where a counter is identified by a bucket index and bucket start timestamp that are both derived from the period. Bindings that share a namespace_id and a period still share a counter for a given key.

• #14968 a88d169 Thanks @petebacondarwin! - Fix local rate limit counters silently resetting after ~10s of inactivity

  The emulated Ratelimit binding kept its counters on the JS heap of an internal Durable Object. workerd evicts idle Durable Objects after around 10 seconds, taking the counters with them, so in wrangler dev you could hit your Worker, pause to look at something, and find your limit had silently reset part way through the window.

  Counters now live in the Durable Object's storage, which survives eviction. They are still cleared by deleteAllDurableObjects(), so reset() from @cloudflare/vitest-pool-workers continues to reset rate limit state between tests, exactly as it does for KV, R2 and D1. Counters are now also written to the persistence directory, so they survive a wrangler dev restart within the same window.

• #14989 daf65f2 Thanks @petebacondarwin! - Surface the full runtime crash report when workerd crashes, and warn when it is restarted

  When workerd crashed, the banner (e.g. *** std::terminate() called with no exception) was reported without its stack trace, because the stack trace was being filtered out along with the ordinary hex-stack noise workerd emits. The crash was therefore impossible to diagnose. The stack: line and the missing-$LLVM_SYMBOLIZER notice that follow a fatal crash banner are now kept, and the whole report is logged at error level.

  Miniflare also recovers from workerd crashes by restarting the runtime, but did so silently, which made a crash look like an unexplained dev server restart. It now warns, including a count so that a repeatedly-crashing runtime is distinguishable from a one-off.