One thing that imho could be very cool too is a method to list all the running workflows
One thing that imho could be very cool too is a method to list all the running workflows
MRight now you can also use the REST API (but something we can look into on the binding)
MInteract with Cloudflare's products and services via the Cloudflare API
M
DThanks, this looks perfect!
MI have a non-Workflow function that fetches, validates with Zod, and then puts data to KV.
I was thinking I could break up each step into a Workflow step, but unfortunately, the data is well above the limit:
Do I just need to put this all into 1 step to make it work?
I was thinking I could break up each step into a Workflow step, but unfortunately, the data is well above the limit:
Serialized RPC arguments or return values are limited to 1MiB, but the size of this value was: 4972045 bytes.Do I just need to put this all into 1 step to make it work?
MBut then I also feel like I lose parts of what Workflows are
MWould it make sense to store the data in an array outside the steps like so:
- Declare variable
- In Step 1: fetch data and store in variable
- In Step 2: use the data from the variable
INo because state outside a step may be cleared at any time: https://developers.cloudflare.com/workflows/build/rules-of-workflows/#do-not-rely-on-state-outside-of-a-step
INot really, because that concept is idempotent so can be put in one step:
- fetch fails, so both ways would fail anyway
- zod validation fails, which causes a failure in both scenarios
- insert into KV fails in which case you can safely fetch again
MIt's more that I would like to have retries on the fetch part only
MLike, if the KV or validation fails, I don't want to redo the fetching
I know I can implement this myself within the step, but I'm looking to learn Workflows and that would feel unintuitive
I know I can implement this myself within the step, but I'm looking to learn Workflows and that would feel unintuitive
IHow expensive is the fetch?
MIt's to a resource I don't own so I'd rather not do any more than I need to. It's also several fetches per run
Cis there a recommended number of workflows per worker. the indefinite queued state is becoming an issue so i'm exploring have each workflow with it's own worker (not an ideal situation and not sure if it might improve things).
Pis the concurrent execution limit likely to be raised significantly (like over 100k) once the beta is complete? (Trying to figure out if I'm better off using DOs or workflows)
YHey so i have a rag workflow pipeline for a hackathon the issue is the steps are failing with
"Too many subrequests." for generating embeddings and storing it into neon db(its a requirement thats why i cant use service binding to D1). are there any subrequest limits in workflows ??
-free tier account
"Too many subrequests." for generating embeddings and storing it into neon db(its a requirement thats why i cant use service binding to D1). are there any subrequest limits in workflows ??
-free tier account
YOk found it 50 subrequests only
MSame as Workers: 50 on free, 1000 on Paid.
MCloudflare Docs
Limits that apply to authoring, deploying, and running Workflows are detailed below.
YThats so bad
YI think I'll have to invoke other workflows from the current one to bypass it
YI hope ?
MYou still have a daily limit on total invocations (it's a free plan). 50 subrequests per Workflow instance is still a fair few.
YIt's 100 invocations per day right. I need to process 50~200 documents at max so maybe send them in a batch of 25-40 to other workflows
MIt’s 100,000 per day (see the docs I linked)
YNice 
YCan I call the worker's endpoint from the workflow in the same application? How do I use service binding in the same worker.
Does using a service binding like this, I can avoid reaching 50 subrequests limit ?
Does using a service binding like this, I can avoid reaching 50 subrequests limit ?
PKeen to understand what kind of limit is envisioned longer term for "Concurrent Workflow instances" if anyone from CF can speak to that?
Oi don't mean to be rude in any way, but is there any ETA on the ghost executions? i really find workflows to be the best thing for my usecase, but i can't use them if a certain amount of executions just get killed and not even retried
Oor if there is anything on my side that i can do to resolve the issue i'd be happy to do so
MFor 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
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
outputInstanceStatus 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
