we don't a delete endpoint for workflows - it's coming :soonsoontm:
we don't a delete endpoint for workflows - it's coming :soonsoontm:
1I cant read 
AI'm getting this:
My Params type look like this:
It looks like Workflows does not support optional params, is that correct?
UNDEFINED_VALUE: Undefined values are not allowedMy Params type look like this:
It looks like Workflows does not support optional params, is that correct?
ASounds good. I have like roughly 10k instances brokenly queued. How to bulk terminate them? 
Fis there a way to know within a step if it's retrying, and if so, can you get the error that made it fail?
ADid we just loose the Wall Time per Step in the Dashboard? It was very nice to see how long a step took for a specific instance
AWhat are some ideas around reducing state byte size. I'm currently facing an issue where I either reach the step count limit or subrequest limit, so the solution is to combine things, but then I'm facing the size limit. I think the state size limit should be easier to increase maybe to 10MiB?
SIn these cases I would recommend storing the result to KV/R2 and just return the key
AAnd retrieving it in the next step again?
Swhen you need it yes
1KV is usually in single milliseconds for hot reads, overall that shouldn't be an issue
AGood idea, haven’t thought about that approach. I’ll see how it will help 
AYeah I was also thinking about KV instead of R2, I think just making sure to clean-up that KV is important, but otherwise it should be totally fine. It’s a background job, so not too concerned about latency
Fany idea why i get this error when using this retry policy
{ retries: { limit: 12, delay: '2s', backoff: 'constant' } }If I remove the retry policy then I don't get any error
Fwould it be possible in the future to await a workflow response inside a workflow? like await would sleep your current workflow instance until the sub-workflow finish
Sit might (or not) happen in the future, but couldn't you make the sub-workflow trigger another workflow at the end? workflow1 -> sub-workflow -> workflow2
Fi mean, yeah, that could work, but it would be good to have some kind of child workflow concept, like temporal.io
Fif the child workflow doesn't succeed then the parent workflow doesn't succeed either
Fand also it is good for propagating cancellation signals when implemented
Fand for code organization 
Syeah I completely understand, we'll take your feedback into account
MHow can I processa large zip file (get from R2) across steps (get/unzip/put to R2) ? I saw the maximum persisted state per step is only 1MiB.
SIn this case, I think that you're better off making (get, unzip, put to R2) into a single step, although you lose some granularity as long you guarantee idempotency you'll be okay
Creally loving workflows so far. I hit the execution limit for my use case and had to use a self spawning approach to get around it. Thanks for giving us this primitive. cool stuff
DHi, anyone have a good idea how to fan out and keep track of when all of the fanouts is done to send a webhook.
I want to do a couple of steps and when done send a webhook. The 512 limit is a bit small sometimes and i need to fan out, so how do i best keep track of the workflows. Should i have a orchestrator workflow that spawns the fanouts and keep track that way? Any other good ideas. Thanks
I want to do a couple of steps and when done send a webhook. The 512 limit is a bit small sometimes and i need to fan out, so how do i best keep track of the workflows. Should i have a orchestrator workflow that spawns the fanouts and keep track that way? Any other good ideas. Thanks
DHey there. Is there a limit to the number of workflow instances that can be queued after exceeding the concurrency limit? Trying to understand what the expected behavior is in that case
CHi. I'm facing issues with workflow instances stuck in a queued state indefinitely and i'm unable to terminate it or anything.
KDoes a single workflow instantiation inherit the subrequests limit defined in worker limits?
https://developers.cloudflare.com/workers/platform/limits/
https://developers.cloudflare.com/workers/platform/limits/
Dhad the same issue. hope they fix this. I think this is just a bug where the queued state cannot be changed.
TThe limits page say that the 30 second cpu limit is per step but it seems like the cpu time is actually for the workflow.
DDo you have any ETA when the workflows will be out of beta? Just worried about potential changes and the need to refactor. Not sure how much really changes between beta and when it is out of beta. I've never used a Cloudflare beta product before...But really love workflows. Makes so many thing easier.
MWe're still very early on - it won't be this year / Jan. Quality > time.
TIs there a clear explanation of how cpu limit works? I'm hitting cpu limit in the workflow even though previously the individual steps logic was well within the cpu limit. It seems like the workflow cpu limit is the sum of the steps cpu usage. Also I have a large try, catch to eventually cleanup but it when I get the CPU exceeded error, the last step never runs
TIs there a difference between using Promise.all and having a for loop that adds the step output to an array? The array will still be comprised of only step.do returns so that should be fine right?
TPlease help, my workflow is crashing and not continuing to next steps due to CPU limit exceeded but I do everything inside steps, there is virtually no work done in the workflow itself.
VVhttps://developers.cloudflare.com/workflows/reference/limits/ total cpu time of workflow is unlimited, but per step (listed as
Compute time per stepCloudflare Docs
Limits that apply to authoring, deploying, and running Workflows are detailed below.
TCan the return of a step be an instantiated class object or will that cause problems if the workflow restarts at some point?
森Can someone confirm if durable objects never gets evicted if it creates a workflow instance? Will I be billed for durations in DO?
森I tried creating an empty DO and have it invoke a workflow that simply sleeps for 30seconds.
The duration should be enough to evict a DO under normal circumstances, however, when the DO is called from the workflow again (via this.env binding), the DO's constructor was never ran again indicating that the instance never got evicted.
The duration should be enough to evict a DO under normal circumstances, however, when the DO is called from the workflow again (via this.env binding), the DO's constructor was never ran again indicating that the instance never got evicted.
IIs there a good way to alleviate this limitation?
In the meantime, I am going to try the method of calling a child Workflow from a Workflow.
In the meantime, I am going to try the method of calling a child Workflow from a Workflow.
MThere’s no guarantee that a DO will be slept right on 30 seconds. Try longer. If you need to keep a DO running, use an Alarm. You will (necessarily) pay for the duration.
NPlayed a little with workflows, its very good & useful. Just wondering, I couldn't figure out if I want to use CF Workflows to hook it up to build a workflow builder tool, where user can drag nodes to create a workflow. How to do so? As of now it doesn't seem possible as each step needs to be statically defined.
MYou can dynamically create steps with an array of objects (config for each step).
MSome folks are already doing that. You don’t need to define steps statically. It’s just code. Create them conditionally, import them, etc. If your run() method calls them, it works.
Mhave been playing around with an idea on top of cloudflare's new workflows...
excited to share it soon – it's truly game changing
excited to share it soon – it's truly game changing
11/21/24, 6:47 PM
TIs there a deadletter "queue" equivalent for workflows/workflow steps? Ie. I want to know when a step stopped retrying so I can manually intervene.