PGitHub
Which Cloudflare product(s) does this pertain to? Workers Runtime, Wrangler, Other What version(s) of the tool(s) are you using? 3.83.0 What version of Node are you using? No response What operatin...
TI'm not sure if I missed to see the answer to the following question anywhere: is an instantiated workflow guaranteed to run on a dedicated worker?
Asking to understand how the worker-specific limits (e.g., subrequests) possibly apply.
Asking to understand how the worker-specific limits (e.g., subrequests) possibly apply.
EAny pointers to docs that describe how workflow can be used with workers for platforms?
edit: looks like this is not currently supported, but would love to understand what the timeline looks like. workflow + workers for platforms is exactly what I need and I'll unfortunately have to forgo workflow until the two can compose together and continue to work on my own workflow layer.
edit: looks like this is not currently supported, but would love to understand what the timeline looks like. workflow + workers for platforms is exactly what I need and I'll unfortunately have to forgo workflow until the two can compose together and continue to work on my own workflow layer.
PMore feedback:
- bug: when triggering a workflow from the UI, the json payload gets stringified (so it does not work at all)
- it would be great to be able to retry workflows/steps from the UI
MRemote isn’t possible while doing dev locally. I.e, can’t access remote R2 while running wrangler dev
So workers with assets is convenient but because it’s not fully fledged out, it depends on how “serious” your project requirements.
The eta for doing running wrangler remotely is this quarter, but I wouldn’t trust CF and assume it would be available sometime early next year
So workers with assets is convenient but because it’s not fully fledged out, it depends on how “serious” your project requirements.
The eta for doing running wrangler remotely is this quarter, but I wouldn’t trust CF and assume it would be available sometime early next year
MApparently, they are working on making workflows have a built in rate limiter. I wouldn’t assume this to be release anytime soon
Without specific numbers than giving advice is difficult but you could potentially do this with breaking up your fanout into multiple workflows. It’s also possible to have a “always on” workflow that manages other workflows although this solution might be less elegant than just using a queue.
Without specific numbers than giving advice is difficult but you could potentially do this with breaking up your fanout into multiple workflows. It’s also possible to have a “always on” workflow that manages other workflows although this solution might be less elegant than just using a queue.
MCan’t you start another workflow from an existing workflow?
PYes, but unlike steps, you don't get the result
KI have a question about workflow IDs. It supports setting the ID in case there is some external ID like a user ID, but it sounds like you cannot reuse IDs. Doesn't that defeat the purpose of being able to reference a workflow?
Is the recommendation to append a timestamp with the external ID or something for a recurring workflow per user ID?
Is the recommendation to append a timestamp with the external ID or something for a recurring workflow per user ID?
SThank MissS :). What's the best way to stay up to date on the progress on Cloudflares side?
PI will unify all workflows in a single one with a switch case, like queues.
DIt is on the Roadmap
SExporting multiple workflows from wrangler.toml seems to cause errors with miniflare locally (and works fine on remote/deployed)
This is similar syntax that I use for queues, but just to double check is this the correct way to add multiple workflows?
I can send you the debug logs, but nothing useful apart from some stuff about LLVM symbolizer. Have validated the issue only occurs when I add the additional workflows, does not occur with just one workflow.
edit: I assume its the same as the issue above https://github.com/cloudflare/workers-sdk/issues/7127 let me know if you need anything from me.
This is similar syntax that I use for queues, but just to double check is this the correct way to add multiple workflows?
I can send you the debug logs, but nothing useful apart from some stuff about LLVM symbolizer. Have validated the issue only occurs when I add the additional workflows, does not occur with just one workflow.
edit: I assume its the same as the issue above https://github.com/cloudflare/workers-sdk/issues/7127 let me know if you need anything from me.
GitHub
Which Cloudflare product(s) does this pertain to? Workers Runtime, Wrangler, Other What version(s) of the tool(s) are you using? 3.83.0 What version of Node are you using? No response What operatin...
MGuys is there any public information on the roadmap? I mean like what to expect when. (I know it’s still in early but I’m very excited that’s why I wanted to learn more)
As far as I understand from the community these are the most expected features or common issues etc.
1) Concurrency settings per workflow or step (maybe other flow control features like throttling, rate limiting etc.)
2) Event based flows like waitUntil API
3) Returning value from workflow and accessing them inside another workflows
4) Local development issues(multiple workflows, id, observability etc)
5) Workflow level clean-up functions such as ‘onFailure’
6) Prioritization on workflow based on key or something similar
7) Limit increase (concurrency, step count etc.)
As far as I understand from the community these are the most expected features or common issues etc.
1) Concurrency settings per workflow or step (maybe other flow control features like throttling, rate limiting etc.)
2) Event based flows like waitUntil API
3) Returning value from workflow and accessing them inside another workflows
4) Local development issues(multiple workflows, id, observability etc)
5) Workflow level clean-up functions such as ‘onFailure’
6) Prioritization on workflow based on key or something similar
7) Limit increase (concurrency, step count etc.)
DUnfortunately I don't think you'll get answers to when type questions, besides ":soontm:"
Dbut trust me you're not alone, I'm also excited about Workflows and eagerly waiting for some of these 
MYeah I know there are a lot of people like us and setting expectations with clear communication would be great in the early stage. Let’s hope that we get answers at least some of them 
DI don't disagree, just saying what I think will be realistic
priorities change all the time, and even if they were to commit to a date/timeline, it's not a 100% guarantee, as a few examples have shown
priorities change all the time, and even if they were to commit to a date/timeline, it's not a 100% guarantee, as a few examples have shown
MYes, you are right but I think nobody expect commitment on a date or something like 100% guarantee on these features/issues. People want to understand the direction and the level of commitment to the product itself. These are not huge things when you have a clear communication. (Not blaming anybody on the team, just saying things can be improved 
)
)
MPeople do interpret dates as commitments 
MHey Matt, let’s forget about the date then.
It would be great if you could inform us on these topics in order to clarify the direction you guys want to go.
Should we expect these features or not? (or any other feature you want to add) Instead of a date, maybe you can share the timeline relative to other features. (like “we are prioritizing this one over this one” etc.)
It would be great if you could inform us on these topics in order to clarify the direction you guys want to go.
Should we expect these features or not? (or any other feature you want to add) Instead of a date, maybe you can share the timeline relative to other features. (like “we are prioritizing this one over this one” etc.)
MI think we've laid these out in this chat - but prioritization does change. We're super early in the beta (only a month in!) and fixing the prioritization means we'd be ignoring folks / the ability to solve problems as they come up.
MMost of these (bar sharing state across Workflows) will likely land in the next 3-4 months. There's not a strict ordering - some of these are easier than others, others need design time/discussion, etc.
I know that's not the answer you want, but it's the answer I'm giving.
I know that's not the answer you want, but it's the answer I'm giving.
MNot quite, but it’s close enough to the answer I was looking for. I appreciate you taking the time to address it. Now, anyone searching for this can find it too. 
MI'm unsure of the best way to implement a fan-out pattern using Workflows. I fetch a list of files, and want to process each one. Should I loop over the files and call step.do, awaiting them all with await Promise.all? Or should I trigger a new "file-process" workflow instance for each of them?
1I've only just started looking at Workflows, I was wondering if it would be suitable for a process where one step requires collecting data from dozens of endpoints (DOs in this case) and waiting until all are returned before going to the next step. Would this be possible?
MYou can do both actually and both have different trade-offs. There is a hard limit (256) for maximum number of steps in a single run. So if the list you want to process is bigger than it you can’t. There is no hard limit for workflows (you can run 100 workflows concurrently tho) however you won’t be able to share state between them without external storage (kv etc.)
MYes, you can do. It’s recommended to make a single fetch call in a step in order not to lose its retry logic and persistency.
Mthanks, didn't immediately see this hard limit in the docs - but it is there, I just missed it. I have a few thousand, so need to trigger a workflow for each.
Punluckily, workflows have limited amount of steps. So only do step.do for each file if you are 100% sure you are not going to have more than 256 files. Regarding triggering a new process for each, it can be done but it does not support batching nor concurrency. What I do to workaround this is one step, and inside I chunk and send batches to a queue. That queue then triggers the workflows.
Also, since having multiple workflows locally does not work, I recommend having a single workflow that dispatches work.
Also, since having multiple workflows locally does not work, I recommend having a single workflow that dispatches work.
PThis is how I connected the pieces myself. Basically a queue endpoint that will forward events to a workflow. The workflow then dispatches with a given id. It's based on convention (each workflow has an id, and the queue name is that id + '-queue') and it allows me to have some type safety. I then pass an object around, so I can compose workflows as you expect.
EAny comment on whether or not workflows will ever support workers for platforms?
SBug in the workflow list versions docs, result should be a collection
https://developers.cloudflare.com/api/operations/wor-list-workflow-versions
https://developers.cloudflare.com/api/operations/wor-list-workflow-versions
Interact with Cloudflare's products and services via the Cloudflare API
CCurious about this as well. Seems a bit of overlap between queues and workflows. Would be nice if there was a guide which outlined reasons to use either
Oso i have a workflow where i have an input pdf and i need to run a claude call. the intermediate step however is to transcribe that pdf via a poll-based service. my question therefore is how do i add sleeps into the polling part - the execution should be under 10-15s, so should i just make it a setTimeout function that is awaited?
Olike i could probably split into two workflow steps - generate the poll URL and then poll to get the transcript
Obut how should i do the sleeps inside the polling
Oactually nvm polling it's a promise.all -> pdfs.map -> polling inside bc it allows for caching of the individual pdf steps
QThe main use case difference I see is that queues seem preferable when I have a lot of one task that I need to do for many objects (e.g., I need to send 1000s of notifications but need to respect the rate limits of a provider, I can queue them all up and then chug along and delay as needed.) Workflows seem to be suited for when you have many different tasks that you need to do for one object (e.g., A user subscribed to my PaaS app, so I need to (1) charge their credit card, (2) spin up some infrastructure, (3) send them a welcome email, and so on while appropriately handling errors/retries at every step). You might be using both together if, for instance, your PaaS app has many users signing up; you might have a queue that triggers a workflow. This is all just based off of my own thoughts as I've read through the docs though so I could be way off
TPretty sure I'm missing something obvious. I've been struggling to understand how the first workflow is created. For other primitives like KV, you first have to create them via wrangler or the dashboard before you can reference their binding in the
wrangler.toml
Shttps://duckduckgo.com/?q=bowie+all+dudes&t=osx
In this example, you can call one programatically await env.MY_WORKFLOW.create() or hit the URL
And there is also trigger from wrangler CLI https://developers.cloudflare.com/workers/wrangler/commands/#trigger
I'm not sure how to automatically trigger based on queues, though
In this example, you can call one programatically await env.MY_WORKFLOW.create() or hit the URL
And there is also trigger from wrangler CLI https://developers.cloudflare.com/workers/wrangler/commands/#trigger
I'm not sure how to automatically trigger based on queues, though
DuckDuckGo. Privacy, Simplified.
TBack one step. I'm not getting to the point of creating a workflow instance. I'm having problem creating the workflow binding itself. Using your example
await env.MY_WORKFLOW.create(), env.MY_WORKFLOW itself is undefined[[workflows]] config in the wrangler.toml? And export the relevant workflow class from the main entry point?PMore feedback on workflows, this time, the UI: the list takes more than 15s to load.
Pand one question: how do we track errors that happen within a step? It seems like they are swallowed. You can see the error on the workflow through the UI, but how would you send them to sentry?
NI would like to see webhook support integrated into a workflow, allowing it to wait for one or more webhooks to be fulfilled before proceeding to the next step.
DThe wrangler.toml config is enough for wrangler to create the bindings when the Workflow get deployed. Can you ensure that you are setting the bindings to env?
TIt looks correct to me. Could it be that I'm trying to access it from an email worker?
MCan you share your code? Did you deploy the Workflow?
Workflows don’t need to be created separately: deploying a Workflow registers it. This section explains it: https://developers.cloudflare.com/workflows/get-started/guide/#5-deploy-your-workflow
Workflows don’t need to be created separately: deploying a Workflow registers it. This section explains it: https://developers.cloudflare.com/workflows/get-started/guide/#5-deploy-your-workflow
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.
