For Paid: ballpark 1k-5k per Workflow.
For Paid: ballpark 1k-5k per Workflow.
DWe are aware of such phenomenon and we are actively working on a fix. Since last week, the chance of getting a ghost execution should have reduced significantly. Further, we are currently testing mechanisms for the system to evict ghost instances. More updates will arrive soon.
OThank you so much!
PThanks good to know - Out of interest, when I look at the DO API, I don't immediately see why it would not be unlimited eventually? Curious what the constraints are
MWe’re still assessing limits. Workflows isn’t just a single DO - we’re doing all of the orchestration, metrics, etc.
Tcan i write workflows in rust
MNot yet. Something we want to land closer to the GA. Focusing on the foundations first.
Tgotcha, good luck ^^
DAre there any updates on getting the Workflow return value through the binding, or Is that on the roadmap?
Adding the Cloudflare API SDK just to get the workflow return value seems to be a bit too much.
I currently have to do a workaround by adding an additional unnecessary step to the end of my workflows, just so I can access the value from the
Adding the Cloudflare API SDK just to get the workflow return value seems to be a bit too much.
I currently have to do a workaround by adding an additional unnecessary step to the end of my workflows, just so I can access the value from the
InstanceStatus output property, which only contains an array with the individual step outputs.
MWhat do you consider the "return" value here? Steps return values. The
run method does not, so there's not a "singular" value.DThanks for the reply Matt. The workflow run method definition has an return value that you can type (it isn't defined as Promise<void>) and the Workflow output (what the
run method returns) is also prominently shown on the Workflow dashboard. So I would assume this is an intended feature of workflows.
DIn the Cloudflare API "Get Logs And Status From Instance" endpoint, the workflow output is also returned separately from the "steps" results. But confusingly, the
output property of the Binding InstanceStatus contains the step results, not the workflow output.
MNot quite - something we're iterating on, specifically because returning a single (size limited) string can be confusing here.
Dhmm okay, from my testing the type of the API docs are wrong. It does indeed return an object value
SBut confusingly, the output property of the Binding InstanceStatus contains the step results, not the workflow output.
You mean in local dev, right? what's the behaviour on a real workflow?
Dhmm it seems like you are right! I just tested it again with my deployed workflow and I do indeed get the workflow output there.
Ssorry about that 
it should be an unknown there - i'll look into it but I think it's an openapi 3.0 limitation
it should be an unknown there - i'll look into it but I think it's an openapi 3.0 limitationDThat is good to know! I hope miniflare will be updated soon to support the same behavior
Syhep i'm looking into it right now
Shttps://github.com/cloudflare/workers-sdk/pull/7575 there you go
GitHub
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...
Dthat was quick looking forward to it! Good idea to keep the step outputs available for debugging locally
looking forward to it! Good idea to keep the step outputs available for debugging locally
AAny updates or issues I can subscribe/follow to, to track progress on this?
Aseems like there might be some sort of outage? when i create new workflows, they have no steps, and when I try to pause or terminate the instances in the dashboard, those API calls return 500 errors like:
Athey also all have a start time of "pending"
Aoh wait - i think i'm running up against the 100 concurrency limit 
Ai would have assumed that workflows that aren't actually running (and are just sleeping) would not count towards the 100 concurrency limit...?
Ahow long is "eventually"? I'm seeing many instances, whose first step is a simple
await step.sleep('wait 24 hours', '24 hours')this is apparently deadlocking my whole account, since these instances which should be
WaitingRunning
Sif you can send me your account id, workflow name and instance id I can look it up 
Supdate your
@cloudflare/worker-typesWorkflowEvent.instanceIdFYI y'all, we've bumped step limits again to 1024 
Athanks for your help! if you look at this one, the instance has been stuck in the "running" status for >24 hours
Awhen it should actually be Waiting state
Athis is a serious issue for us because it's causing us to hit the 100 concurrency limit
Awe're actually rebuilding our own task system outside of workflows because it's so broken 
SYou can try to terminate those hanging ones, to free up space - feel free to send any instance thats stuck to my dms (to not clog up this chat)
Ci love y'all 
@Seekerdasbatatas thanks for keeping updates coming our way and improving the product each day according to the user needs. you guys are the best!
@Seekerdasbatatas thanks for keeping updates coming our way and improving the product each day according to the user needs. you guys are the best!
WHowdy all, I'm trying about workflow and saw this doc to running it locally, https://developers.cloudflare.com/workflows/build/local-development/, is there a way for me to test out the workflow? I know that
npx wrangler workflowCloudflare Docs
Workflows support local development using Wrangler, the command-line interface for Workers. Wrangler runs an emulated version of Workflows compared to the one that Cloudflare runs globally.
MThe doc you linked shows the steps: https://developers.cloudflare.com/workflows/build/local-development/#start-a-local-development-session
Cloudflare Docs
Workflows support local development using Wrangler, the command-line interface for Workers. Wrangler runs an emulated version of Workflows compared to the one that Cloudflare runs globally.
FIs there a way to delete workflows on our accounts? I can’t seem to find it either in the dashboard or api
FOops! What happens if you delete the worker bound to a workflow? Can that workflow still be used by another worker?
HI'm using workflows and I really like the built-in design to retry individual steps, very much like a multi-queue solution for each step.
However, I'm also using queues to trigger N instances of the workflow as I want to space out some external calls, so I'm using delay with the queue.
But I'd very much like the workflow to receive the original batch.
This would allow for a much more robust acknowledgement and retry mechanism. If the workflow has access to the JS API of the queue batch, it will be able to control acknowledgment of the message. By retrying the queue message, it will be able to revert back executed steps by retrying the queue message and triggering a new workfow instance resetting the state.
The step sleep is not enough for that.
Currently, I need to resort to acknowledging all messages in the queue batch as soon as the workflow is triggered regarless if it's successful.
However, I'm also using queues to trigger N instances of the workflow as I want to space out some external calls, so I'm using delay with the queue.
But I'd very much like the workflow to receive the original batch.
This would allow for a much more robust acknowledgement and retry mechanism. If the workflow has access to the JS API of the queue batch, it will be able to control acknowledgment of the message. By retrying the queue message, it will be able to revert back executed steps by retrying the queue message and triggering a new workfow instance resetting the state.
The step sleep is not enough for that.
Currently, I need to resort to acknowledging all messages in the queue batch as soon as the workflow is triggered regarless if it's successful.
ADoesn't seem to work with
wrangler types --experimental-include-runtime
DAssuming that I have a workflow which at the end returns something, can I later retrieve that value using
env.WORKFLOW.get(id).status().outputAh, I guess this is part of the following limit:
Retention limit for completed Workflow state: 3 days; 30 days
AJust as an FYI, I think there's some out of date info in the docs referring to
event.paramsevent.payload
WAsking a question re the
the limits:
I am using this to get the size of the return value
however, I notice that the value returned and the actual value shown when an error is thrown can be quite different.
how can I reliably check what is the size of a return value before returning it?
(guess this is not specific to Workflows, but it's relevant in this context because a workaround I've seen is to use ReadableStream, but that wouldn't work because of the max persisted state per step limit)
Serialized RPC arguments or return values are limited to 1MiBthe limits:
- maximum persisted state per step is 1MiB
- Workers return value can only be 1MiB
I am using this to get the size of the return value
however, I notice that the value returned and the actual value shown when an error is thrown can be quite different.
how can I reliably check what is the size of a return value before returning it?
(guess this is not specific to Workflows, but it's relevant in this context because a workaround I've seen is to use ReadableStream, but that wouldn't work because of the max persisted state per step limit)
MAlways the code as it was deployed. We’re thinking about how to enable some options here. Lots of divisive opinions.
BHey guys is it not possible to remove a deployed workflow?
