Was doing some load tests and noticed that if I start a bunch of workflows quickly the dashboard kin
Was doing some load tests and noticed that if I start a bunch of workflows quickly the dashboard kinda becomes really slow 
DAnyone else experience this? 
DI was only starting like 26/s tho 
DOnce I stop the load test and wait a few min for the workflows to finish .. it loads fine
Ois there some concurrency limit for workflows, and after that the ability to queue in items for processing? i have a cronjob that potentially fetches a lot of data to be processed at once and i want to send it to a workflow, but i don't want to hit the concurrency limit
Othis seems like exactly what i want but i can't seem to find the answer
Oadditionally is there a way to limit the amount of concurrent workflow runs overall? like if i have 100 waiting for API calls it won't start up more?
MNope, not yet. I think they are working on it.
Swe are aware of the performance issue and hopefully fixing it very :soonsoontm:
A
Awe're seeing a LOT of these "Attempt failed due to internal workflows error" failures
Afor days, in a great many of our workflow instances
Ais anyone else seeing this? does anyone have insight into what these errors are?
Ohey there. i'm working with a HTMLRewriter and i seem to be getting errors with an RPC stub not being disposed. i think it's the rewriter because of essentially the same error here. is this an issue on my side or an issue within workers?
DI also noticed... I have a sleep step like so
await step.sleep('wait on something', '1 second') but here it says the wall time for this step is 254ms .. any idea why it's lower than what the wall time should be?
Dit would also be nice if it showed the sleep step name (i.e - "wait on something").. even tho it is just a sleep.. instead of just showing the name as "Sleep" 
DMaybe like
wait on something (Sleep)DIt's easy to tell what sleep step it is, since I only have 1 sleep step.. but if I had multiple.. it would be easier to tell which sleep step is what very quickly
AI hit a wall with Workflows:
What is the workaround for worklows? For service bindings, it is to use streams.
Serialized RPC arguments or return values are limited to 1MiB which I think happens when the returned values of a step are larger than 1MiB.What is the workaround for worklows? For service bindings, it is to use streams.
AYeah merged 3 steps into 1. Not ideal.
Swdym? in theory you can save/load in a different storage provider without compromising granularity
AIt's just a lot faff to add R2/offloading (not being used in this project).
SI understand, my future OSS side project that I've wanting to do might solve that: is to allow some nice abstractions on top of workflows (like natively supporting other storage providers, and other cool stuff that i've been noting down)
FHey 
,
loving workflows so far, one thing I noticed is when you use the
While when I trigger it via cli, it works without any problems.
,loving workflows so far, one thing I noticed is when you use the
Trigger Button to trigger a workflow, the Params are submitted with some extra characters While when I trigger it via cli, it works without any problems.
1try a
JSON.parse() on the params first1But tbh not sure if the
Trigger button doing the stringify, or if wrangler not stringifying would count as a bug hereFThanks 
for the feedback. I think for the button you can only enter „valid json“ so a stringified version is not validated in the modal text input. But yeah you are right if i input a non stringified json, after clicking trigger it gets stringified which makes my workflow fail.
But the stringified cli trigger payload works
for the feedback. I think for the button you can only enter „valid json“ so a stringified version is not validated in the modal text input. But yeah you are right if i input a non stringified json, after clicking trigger it gets stringified which makes my workflow fail. But the stringified cli trigger payload works
LI noticed this as well. You can use a JSON parse when testing through the dashboard but keep in mind that this doesn’t happen when you are actually sending JSON to the workflow when you create a run so don’t leave it in for production
SIs workflows down, some of my requests ahve been stuck in queue for a few minutes and just aren't being procesed.
I am sending thousands of requests so there is some scale to it.
I am sending thousands of requests so there is some scale to it.
SAlso when running more than 2 workflows per second im getting throttled.
Sometimes responses from workflows rest API endpoint to start a new workflow is taking up to 40seconds
Sometimes responses from workflows rest API endpoint to start a new workflow is taking up to 40seconds
DHow many Workflows do you have running?
We are aware of the some performance issue under heavy load (per account) and we are working on fixes for it
We are aware of the some performance issue under heavy load (per account) and we are working on fixes for it
DIs this something new for you? I mean, did you see it in the past?
SFirst time I’ve ran a large workload
FIs there a way to re-run a workflow after sleep when the workflow has finished running?
FMy use case is that I'm writing a workflow to do a visual ping to a website every X minutes and would love to automatically re-run the workflow after it's finished running
FBut not sure if this is even possible
DNot for the moment. A restart feature is on our roadmap
FRoger
FIf you need some API ideas, Restate has a good API for scheduling workflow execution
FYeah, that's it!
FThey have a feature called delayed calls:
FThey have other cool ideas as well that could be useful in workflows, like access to storage (similar to Durable Objects), the ability to have more handlers inside a workflow to return statuses, or whatever you want to return about the current workflow instance, signals, etc.
F
LIs there no TS support? How do you write usable code then?
LI'm not DHH.
MAll of the examples are in TypeScript.
MI’d recommend starting with the guide and then coming back here if you get stuck: https://developers.cloudflare.com/workflows/get-started/guide/
Cloudflare Docs
Workflows allow you to build durable, multi-step applications using the Workers platform. A Workflow can automatically retry, persist state, run for hours or days, and coordinate between third-party APIs.
CIs the "Cross-script calls" feature supposed to work for Workflows local development (
I get
wrangler dev)? (See https://developers.cloudflare.com/workflows/build/workers-api/#cross-script-calls)I get
Worker "workflows:test-item-workflow"'s binding "USER_WORKFLOW" refers to a service "core:user:my-app-workflows", but no such service is defined., even though I am setting the name of the other worker with wrangler dev --name my-app-workflows
Lwere they updated or it was always like that?
MThey were always like that, from the beginning. You can check the commit history: https://github.com/cloudflare/cloudflare-docs/commits/production/src/content/docs/workflows/get-started/guide.mdx