cloudflare/workers-sdk miniflare@4.20260317.2

on GitHub

Patch Changes

• #11753 b8f3309 Thanks @ruifigueira! - Added the following improvements to local Browser Rendering binding in Miniflare:

  • Local Chrome version upgraded to 126.0.6478.182
  • Reciprocate browser websocket close events

• #12986 5aaaab2 Thanks @petebacondarwin! - fix: allow mixed d1Databases records containing both string and object entries

  Previously, passing a d1Databases config that mixed plain string values and object entries (e.g. { MY_DB: "db-name", OTHER_DB: { id: "...", remoteProxyConnectionString: ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.

• #12986 5aaaab2 Thanks @petebacondarwin! - fix: allow mixed kvNamespaces records containing both string and object entries

  Previously, passing a kvNamespaces config that mixed plain string values and object entries (e.g. { MY_NS: "ns-name", OTHER_NS: { id: "...", remoteProxyConnectionString: ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.

• #12987 f8516dd Thanks @petebacondarwin! - fix: allow mixed pipelines records containing both string and object entries

  Previously, passing a pipelines config that mixed plain string values and object entries (e.g. { MY_PIPELINE: "pipeline-name", OTHER_PIPELINE: { pipeline: "...", remoteProxyConnectionString: ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.

• #12952 9c9fe30 Thanks @petebacondarwin! - fix: allow mixed r2Buckets records containing both string and object entries

  Previously, passing an r2Buckets config that mixed plain string values and object entries (e.g. { MY_BUCKET: "bucket-name", OTHER_BUCKET: { ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.

• #13015 6a6449e Thanks @petebacondarwin! - fix: disable undici Pool request timeouts for local dev

  Miniflare's undici Pool instances were using the default headersTimeout and bodyTimeout of 300 seconds (5 minutes). Any request taking longer than that — streaming responses, large uploads, long-polling, or compute-heavy Workers — would be silently killed with a "request failed" error.

  Setting both timeouts to 0 disables them entirely, which is the correct behaviour for a local development tool where there is no reason to enforce request timeouts.