Minor Changes
-
#15648
52c0e9fThanks @tpmmorris! - Expose configured Cron Triggers and one-off scheduled dispatch through Local ExplorerMiniflare's V4 Worker options now accept exact Cron Trigger expressions. Local Explorer reports them in Worker metadata and can dispatch a scheduled event to an exact local or peer Worker name with a chosen cron expression and time.
-
#15652
44f5295Thanks @tpmmorris! - Package the Cron Triggers interface in Local ExplorerThe Local Explorer assets now include an interactive Cron Triggers destination for one-off local scheduled-handler testing.
-
#15786
bdda4c3Thanks @ThomasRubini! - Support UDP connect handlers in local developmentThe experimental
connectconfiguration now acceptsprotocol: "udp", with optionalidle_timeout_msandmax_pending_bytessettings. UDP datagrams are delivered to the Worker'sconnect()handler using workerd's value-mode socket streams, and can be tested withMiniflare#dispatchConnect({ protocol: "udp" }). -
#15779
fc3cbaaThanks @Naapperas! - Supportworkflowentries in theexportsconfiguration mapA Worker can now declare the Workflows it defines in
exports, keyed by theWorkflowEntrypointclass name:A
workflowexport accepts the same settings as aworkflowsbinding:limits,concurrency,schedules, anddefault_retention.wrangler deployandwrangler versions uploadsend these entries to the upload API by name, andwrangler deployandwrangler triggers deployprovision the Workflow with its settings, just as they do forworkflowsbindings owned by the Worker. A Workflow may be declared both as a binding and as an export, as long as both declarations use the same class and do not set the same setting to different values. A binding to another Worker's Workflow cannot share a name with an export.@cloudflare/configadds the matchingexports.workflow()helper. Local development does not yet act on these entries.
Patch Changes
-
#15796
be72815Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"The following dependency versions have been updated:
Dependency From To @cloudflare/workers-types ^5.20260921.1 ^5.20260923.1 workerd 1.20260921.1 1.20260923.1 -
#14847
940c692Thanks @TheSaiEaranti! - Emulate the deterministic-ID uniqueness contract in the local Workflows bindingThe local Workflows binding now matches the documented production behavior for deterministic instance IDs:
create({ id })with an ID that already exists throws(instance.already_exists)and retains the existing instance, andcreateBatch()skips IDs that already exist or repeat within the batch, excluding them from the result instead of creating duplicate executions. Previously both paths silently created duplicates, so code relying on deterministic IDs for idempotency (for example a Queue consumer creating one workflow per message) appeared to work locally while double-executing workflow bodies.
{ "exports": { "MyWorkflow": { "type": "workflow", "name": "my-workflow", "limits": { "steps": 100 }, "schedules": "0 * * * *" } } }