github cloudflare/workers-sdk miniflare@4.20260730.0

Minor Changes

  • #14685 01d7020 Thanks @edmundhung! - Add JSON output to /cdn-cgi/handler/email

    The /cdn-cgi/handler/email endpoint now accepts ?format=json to return the email handler result as JSON, including its outcome, rejection reason, forwarded messages, and replies. Requests without format=json still return the existing text outcome for backward compatibility.

Patch Changes

  • #14929 48f0c6c Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

    The following dependency versions have been updated:

    Dependency From To
    @cloudflare/workers-types ^5.20260722.1 ^5.20260730.1
    workerd 1.20260722.1 1.20260730.1
  • #14810 d7f38c3 Thanks @allocsys! - Fix the local Images binding transform (env.IMAGES.input(...).transform(...)) ignoring the fit, gravity, and background options. Previously, local dev always letterboxed transformed images with black bars regardless of the options passed in. Local dev now respects fit, gravity, and background, matching production Images binding behavior.

  • #14850 5c25cfe Thanks @exKAZUu! - Disable the keep-alive timeout on the loopback server

    The loopback server (which serves custom service bindings, @cloudflare/vite-plugin's module transport, and other workerd → Node callbacks) used Node's default server.keepAliveTimeout of 5 seconds. workerd pools and reuses connections to the loopback server, so Node closing an idle pooled socket raced with workerd sending the next request on it, making that request fail with Network connection lost. The failure is probabilistic and load-dependent; under @cloudflare/vite-plugin with a large SSR module graph and a cold optimizer cache (thousands of fetchModule calls with multi-second idle gaps between bursts), it broke most dev sessions. Disable the idle keep-alive timeout on the loopback server, mirroring the undici pools used for dispatch in the opposite direction.

  • #14914 1f61001 Thanks @nickpatt! - Capture Workflows invocations in local observability

    When local observability is enabled, the Workflows engine service is now attached to the trace collector (like every user worker), so workflow runs show up in the Local Explorer's Observability view attributed to the workflow. Previously the engine ran outside the per-user-worker tail wiring, so workflow invocations left no traces, spans, or logs in the local store.

Don't miss a new workers-sdk release

NewReleases is sending notifications on new releases.