Hey team, is there an ETA on when the concurrent execution limit of 100 will be bumped? would the wo

Hey team, is there an ETA on when the concurrent execution limit of 100 will be bumped? would the workflows in await steps count toward the concurrent execution limit?
we have workflows which have a total execution time of less than 10 m and want to be able to run 50K per minute and it is not a constant rate.

ᴀᴀkqj Hey team, is there an ETA on when the concurrent execution limit of 100 will be ...

Matt Silverlock•12/28/24, 2:31 AM

Not yet. Are you asking for ~833/sec or much higher? Have you tried using a Queue to manage a backlog / back off?

ᴀ

ᴀkqjOP•12/28/24, 3:10 AM

yes 900/s or more concurrent WF, right now we are using the queue and are event based, liked the workflow model which fits our use case, we want to have multiple campaign workflows which would create multiple subscribers workflow. subscribe workflow will perform bunch steps and send out the content

ᴀᴀkqj yes 900/s or more concurrent WF, right now we are using the queue and are event ...

Matt Silverlock•12/28/24, 5:43 PM

We’re still early-ish in the beta so won’t be 900-1000+ concurrent overnight. Recommend using a Queue here - even at scale, a Queue is going to give you the mechanisms to manage the backlog

Carl•12/28/24, 7:55 PM

any update on the infinite queued instances dilemma. currently, i'm unable to start a new instance of any workflow account wide.

CCarl any update on the infinite queued instances dilemma. currently, i'm unable to st...

Matt Silverlock•12/28/24, 10:18 PM

This should have been fixed last week. Can you share your account ID so we can see what’s off here?

MMatt Silverlock This should have been fixed last week. Can you share your account ID so we can s...

Carl•12/29/24, 8:07 AM

e62618c17826d22a8c7630187706413b

CCarl e62618c17826d22a8c7630187706413b

Matt Silverlock•12/30/24, 11:22 AM

This should be fixed now: we believe we fixed the root cause on this (metadata out of sync).

MMatt Silverlock This should be fixed now: we believe we fixed the root cause on this (metadata o...

Carl•12/30/24, 12:40 PM

unfortunately still facing the issue. both for existing workflows and a new basic example one i created to test.

CCarl unfortunately still facing the issue. both for existing workflows and a new basi...

Matt Silverlock•12/30/24, 2:17 PM

@Diogo Ferreira is looking into this now

felixv•12/30/24, 11:34 PM

Is there a way to create a workflow and wait until it’s finished ?

what would be the most elegant way.

eg. I have a hono api. Then I wanna call a workflow and once it’s finished return the result.

Is polling via promise resolve the best ?

Ffelixv Is there a way to create a workflow and wait until it’s finished ? 🤔 what would...

tadhglewis•12/31/24, 12:02 AM

It doesn't seem like a good fit to me. You're trying to do asynchronous work in a synchronous flow. Why not just do your workflow logic in the hono API?

tadhglewis•12/31/24, 12:04 AM

The entire thing with Workflows is it doesn't provide guarantees on when it will finish or how quickly. You would run into issues with connection timeouts etc if you try to keep an API connection open

tadhglewis•12/31/24, 12:05 AM

It's hard without knowledge of what you're doing but a common standard if you need to notify a consumer once async work is done is by sending them a webhook

jrydberg•12/31/24, 12:23 AM

Any plans on increasing the step result size limit from 1MB ?

felixv•12/31/24, 7:24 AM

Awesome! Thanks

. That makes a lot of sense.

tadhglewis•1/1/25, 2:11 AM

Are there plans to make Workflows recoverable? As in, previously I was using a queue + worker and failed items would go to the dead letter queue, be manually investigated and redrived/replayed if there was a code bug.

Will it be possible to retry "dead letter" Workflows?

Ttadhglewis Are there plans to make Workflows recoverable? As in, previously I was using a q...

Matt Silverlock•1/1/25, 2:03 PM

How would you want this to work? Replay the instance (which would make tracking by ID complicated) with the same params?

I think this is tied up in how we tackle versioning, which is something we’re working on but non-trivial. Some folks want workflow instances to be immutable; others for them to reflect code updates; and a few want them to update between steps (unlikely).

I could imagine a

.create({fromExisting: <id>})

.create({fromExisting: <id>})

or similar that allows you to spawn a NEW instance using the input params of the old.

progame•1/1/25, 6:04 PM

what

jrydberg•1/1/25, 8:32 PM

I've started playing with workflows, and ran into the following issue. wonder if it could be related to Workflows?

https://discordapp.com/channels/595317990191398933/1324112336121888858/1324112336121888858

MMatt Silverlock How would you want this to work? Replay the instance (which would make tracking ...

tadhglewis•1/1/25, 11:29 PM

So for context, my workflow does something like

Creates a new workflow instance with an account id which needs creating/updating
Fetch data from internal db and create/update data in a 3rd party via their API

I need every workflow to have always passed (and if one fails, send an alert via our monitoring). I am also planning on surfacing the workflow status to the end consumer by adding another step which updates our internal DB to reference the workflow instance.

Having said that, for my use case, just creating a new instance with the same params would work. I suppose I could do this already using the Workflows API

Ttadhglewis So for context, my workflow does something like 1. Creates a new workflow insta...

Matt Silverlock•1/2/25, 1:37 PM

Right. We could make that (duplication) easier, but if the previous instance’s data/state expires, it’d be more error prone.

Ttadhglewis It doesn't seem like a good fit to me. You're trying to do asynchronous work in ...

Focux•1/2/25, 5:45 PM

I disagree with this. Sometimes, for some tasks, you don't want the async nature of the workflow but the durable and retry functionality without having to implement it yourself.

Focux•1/2/25, 5:49 PM

Some workflows engine already supports that, like Restate, for example.

FFocux I disagree with this. Sometimes, for some tasks, you don't want the async nature...

tadhglewis•1/2/25, 9:38 PM

IMO sounds like bad practice. If you want retries, configure that in your HTTP client (Axios, ky etc).

I've never heard of Restate and it doesn't look like it's being used at scale.

Ttadhglewis IMO sounds like bad practice. If you want retries, configure that in your HTTP c...

Focux•1/2/25, 9:39 PM

You lost me at "it doesn't look like it's being used at scale", end of discussion lol

Hugi•1/2/25, 9:39 PM

@isaacmcfadyen @isaacmcfadyen

tadhglewis•1/2/25, 9:40 PM

Anyhow I was specifically talking about CloudFlare Workflows and how they work (asynchronously)

Focux•1/2/25, 9:41 PM

And I was talking about durable workflows and how the only upside is not async execution

Focux•1/2/25, 9:42 PM

If that's the case, there are better-suited tools for that use case

andyy•1/3/25, 11:09 AM

I'd like to be able to treat a workflow parameter as secret similar to how workers secrets are treated - i.e. value only retrievable within the workflow execution itself (vs. currently parameter values are output in workflow dashboard/logs etc). doesn't seem possible currently but seemed worth mentioning. use case is to pass in short-lived external service authentication credentials to a workflow run that are unique to each user in a multi-tenant system (perhaps there's a better way to implement this). thanks!

Aandyy I'd like to be able to treat a workflow parameter as secret similar to how worke...

tadhglewis•1/3/25, 12:10 PM

I'd assume these credentials are stored somewhere in your application database?

tadhglewis•1/3/25, 12:11 PM

You'd probably be better off passing in a key/ID which correlates to Secrets Manager (or a database row) which contains the creds

Ttadhglewis You'd probably be better off passing in a key/ID which correlates to Secrets Man...

andyy•1/3/25, 1:26 PM

thanks for the suggestion. the nice thing about passing (short-lived) secrets in as a parameter is that in a multi-tenant system it keeps simple and effective separation between tenants with a zero-trust style architecture - having the workflow worker retrieve secrets via ID requires giving the workflow access to all secrets. possible, but a greater surface area for vulnerabilities. there's also no need for the workflow to talk to other internal services if everything can be simply passed in as a param.

tadhglewis•1/3/25, 1:28 PM

Ah I realise my suggestion isn't very useful either as you can see the steps output - so if you had a step to fetch the creds, it'd be exposed.

Seems like having hidden/secret params makes sense

Ddave hmm, any ideas on why it would be stuck in `queued`?

shlomo•1/3/25, 6:41 PM

Did you ever figure out why this was the case or some help bec. Facing this same issue and have no error logs or context as to why

Kkchro3 we're seeing an issue where some workflows are getting stuck in the queue. I onl...

shlomo•1/3/25, 6:44 PM

Did you ever figure out what was causing this issue?

BBahaa Just dropping by to give my experience, workflows being marketed as a way to do ...

Chaika•1/3/25, 8:00 PM

Sleeping instances should eventually not count towards the concurrent limit: workflows
I think they might be having some issues with that tho, it is beta after all

Jadugar_Jaggu•1/3/25, 9:17 PM

Hi,

I was testing the workflow and performing some heavy tasks (really intensive ones), and occasionally encountered the error:

"The step crashed the worker (or exceeded CPU/Memory limits) during this attempt."

This error occurs in certain steps, but since most steps follow the same function with different arguments, it doesn't seem to be an issue with the function itself.

The primary challenge is that the error message doesn’t specify whether the issue was due to exceeding memory limits or CPU time limits. This lack of clarity makes it difficult to diagnose and optimize the code effectively.

It would be greatly beneficial if the error message provided precise details about the cause of the crash—whether it was due to memory usage or CPU time limits. Such information would significantly aid in troubleshooting and improving the performance of the workflow.

darren•1/4/25, 11:15 PM

Hello! I’ve been building with Workflows for the past couple of weeks. The ergonomics are really nice and I’m excited about the potential of this product.

I’ve started to notice frequent errors when attempting to make external network requests. Everything was working as expected until Dec 29. Now the majority of my requests are returning some variation of a “Connection error”.

I’m seeing this error with a few different API’s, including:

OpenAI
Resend
Cloudflare AI

I’ve also tried using Cloudflare’s AI Gateway, but didn’t notice a difference.

Example of a failed run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/5a94adfd-e01d-4f83-bf94-8729a9bbe7fc

Example of a successful run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/1a765ea9-6e2a-4ce6-9c7c-18bf1c86d26e

Please let me know if there’s more info I can provide!

juanferreras•1/5/25, 3:23 PM

started playing with workflows yesterday – what an amazing product

Hey team, is there an ETA on when the concurrent execution limit of 100 will be bumped? would the wo

Similar Threads

Similar Threads

Similar Threads