Changelog
Improved Workflows execution that prevents Workflows instances from getting stuck, and allows stuck instances to become unstuck.
Also, improved the reliability of Workflows step retry counts, and improved Instance ID validation.
With this release, some bug were fixed:
event.timestampis nowDate, fixing a regression.- Fixed issue where instances without metadata were not terminated as expected.
Also, this release makes Workflows execution more reliable for accounts with high loads.
Previously, in local dev, the output field would return the list of successful steps outputs in the workflow. This is not expected behavior compared to production workflows (where the output is the actual return of the run function).
This release aligns the local dev output field behavior with the production behavior.
Workflows can now be terminated and pause instances from a queued state and the ID of an instance is now exposed via the WorkflowEvent parameter.
Also, the mechanism to queue instances was improved to force miss-behaved queued instances to be automatically errored.
Workflows now allow you to define up to 1024 steps in a single Workflow definition, up from the previous limit of 512. This limit will continue to increase during the course of the open beta.
Introduction of a new mechanism to queue instances, which will prevent instances from getting stuck on queued status forever.
Workflows now allow you to define up to 512 steps in a single Workflow definition, up from the previous limit of 256. This limit will continue to increase during the course of the open beta.
If you have Workflows that need more steps, we recommend delegating additional work to other Workflows by triggering a new Workflow from within a step and passing any state as parameters to that Workflow instance.
You can now call create() without any arguments when using the Workers API for Workflows. Workflows will automatically generate the ID of the Workflow on your behalf.
This addresses a bug that caused calls to create() to fail when provided with no arguments.
Local development with wrangler dev now correctly supports multiple Workflow definitions per script.
There is no change to production Workflows, where multiple Workflow definitions per Worker script was already supported.
Workflows, a new product for building reliable, multi-step workflows using Cloudflare Workers, is now in public beta. The public beta is available to any user with a free or paid Workers plan.
A Workflow allows you to define multiple, independent steps that encapsulate errors, automatically retry, persist state, and can run for seconds, minutes, hours or even days. A Workflow can be useful for post-processing data from R2 buckets before querying it, automating a Workers AI RAG pipeline, or managing user signup flows and lifecycle emails.
You can learn more about Workflows in our announcement blog, or start building in our get started guide.