"You can set your own instance ID" - OK that is not clear from the docs and examples. I think all th

"You can set your own instance ID" - OK that is not clear from the docs and examples. I think all the examples I have seen use crypto to create a unique instance. Also, I like the idea of the workflow triggering the actual order. Didn't think of that. Thanks!

Dddsgadget "You can set your own instance ID" - OK that is not clear from the docs and exam...

felixnorden•4/11/25, 11:13 AM

What we tend to do is use a shared UUID for various items and prefix with what the consumer is, e.g., workflow-${uuid}workflow-${uuid} so you can debug more easily too if/when things go south

Dddsgadget "You can set your own instance ID" - OK that is not clear from the docs and exam...

Matt Silverlock•4/11/25, 11:14 AM

Where can we make this clearer? Documented here: https://developers.cloudflare.com/workflows/build/workers-api/#create

An ID is automatically generated, but a user-provided ID can be specified (up to 64 characters 1). This can be useful when mapping Workflows to users, merchants or other identifiers in your system.

We kept the tutorial simpler (because otherwise we get feedback that we’re introducing too much!)

Ffelixnorden What we tend to do is use a shared UUID for various items and prefix with what t...

Matt Silverlock•4/11/25, 11:15 AM

100% this. Same as you would with Temporal or other async workflow systems.

MMatt Silverlock Where can we make this clearer? Documented here: https://developers.cloudflare.c...

ddsgadgetOP•4/11/25, 11:18 AM

Yeah, I see it there now. I'm not sure how you can make this clearer. It's easy to miss that. And also, I generally read examples first and learn from that, and don't go back to the docs unless I need something new or have a bug. And all the examples either don't create the instance and let it be done automatically or they use crypto. So that's how I've been doing it. Maybe have an example with an instance ID that is user-provided? Not really sure.

Dddsgadget Yeah, I see it there now. I'm not sure how you can make this clearer. It's easy ...

Matt Silverlock•4/11/25, 11:21 AM

Yeah - maybe we can link out from the guide so it’s mentioned but doesn’t pollute the tutorial / add too much up front

Matt Silverlock•4/11/25, 11:21 AM

Or a code comment (or both)

MMatt Silverlock What version of `wrangler` are you using? Make sure it’s the latest (4.8.0 or la...

fredviken•4/11/25, 11:23 AM

Both the workers were using 4.9.1. I just tried updating to the latest (4.10.0) but I still get the same error message

felixnorden•4/11/25, 3:24 PM

Is there a way to use the chrome debugger inside the workflow steps? I'm unable to hook into it from the main pool, but the worker and DOs work there. Trying to figure out why I'm not getting error logs in a dedicated class that's being called in the step.

WWallslide I was thinking workflows would be a great usecase for handling IOT messages, but...

boop•4/11/25, 5:52 PM

The way I'm getting around the limit is popping messages into a queue and then batching 100 messages or every 10 seconds to a workflow. When hitting the ratelimit, the queue will redeliver in the next batch

boop•4/11/25, 5:54 PM

Although my usecase isn't time sensitive, it's handling user registrations

MMatt Silverlock One request per Workflow. You can retry any that fail (although that should be v...

hugo martins•4/11/25, 6:52 PM

We can retry them, of course — but workflows are meant to be about durable execution. What I was expecting was a way to trigger multiple distinct workflows transactionally with a single request. That way, if the Cloudflare Workflows API goes down or we hit a quota/limit issue, either all workflows start or none do — instead of ending up in a half-started, inconsistent state.

By having to manage retries ourselves, we’re essentially recreating the very problem that workflows are supposed to solve, aren’t we?

Hhugo martins We can retry them, of course — but workflows are meant to be about durable execu...

Matt Silverlock•4/11/25, 6:58 PM

How are you solving this today/elsewhere? What requires these Workflows to be tightly coupled in a way that can’t be solved by using one Workflow vs trying to spread across many?

(To be clear, this doesn’t mean we wouldn’t consider a transactional API, but it’s non-trivial across multiple unrelated Workflows, because that has a performance + complexity cost)

jasperagrante•4/12/25, 3:59 PM

What's the best way to use Queues to limit the concurrency of Workflows? Or would it be just polling the workflow status and using setTimeout to sleep on the consumer before ack'ing the message?

WWallslide what if you had workflow steps dumping their work into queues

jasperagrante•4/12/25, 5:00 PM

Ohh yeah, that might work! I've just discovered waitForEventwaitForEvent earlier. I might be able to queue from the workflow and use send event to resume the flow. Thanks!

Isak•4/14/25, 4:02 PM

Is this released or coming in the future? "When creating a Workflow instance, you can set a shorter state retention period if you do not need to retain state for errored or completed Workflows."

IIsak Is this released or coming in the future? "When creating a Workflow instance, yo...

Matt Silverlock•4/14/25, 7:21 PM

Coming soon.

aza547•4/14/25, 9:43 PM

Hello, is there a subrequest limit on workflows? Trying to work out if it fits my use case which I expect to need to make several thousand subrequests to R2. I was looking at a scheduled worker job but I think that certainly does have a 1000 subrequest limit. The docs seem a little unclear in that there is no explicit limit here but it states "Many limits are inherited... [from Workers]".

Cloudflare Docs

Limits · Cloudflare Workflows docs

Limits that apply to authoring, deploying, and running Workflows are detailed below.

D Trombett•4/14/25, 10:09 PM

Yep, the limit is the same as workers

aza547•4/14/25, 10:10 PM

Thanks!

s̸̘̩̓̍ẻ̸͕ͅå̶̡͖ṅ̴̹̊͜•4/14/25, 10:11 PM

How can we disable retries? Is is sufficient to set retriesretries to 00?

We did this and still are still seeing retries in our dashboard.

Ss̸̘̩̓̍ẻ̸͕ͅå̶̡͖ṅ̴̹̊͜How can we disable retries? Is is sufficient to set `retries` to `0`? We did th...

Jadugar_Jaggu•4/15/25, 12:23 PM

you have to configure it for every step

Marco Aleixo•4/15/25, 12:40 PM

When we will be able to delete Workflows?

conneo•4/15/25, 2:11 PM

Hi, isn't it possible to search for a workflow run by ID in the CF Dashboard? Or will that be added soon?

Kuririn•4/15/25, 2:27 PM

My workflow works locally but when deployed I get error status on my steps, but I don't have idea how to check the error message.

wrangler tail is not showing any console / error logs
worker logs doesn't show anything either (only invocation)
same for workflows dahsboard (just show status: error)

Kuririn•4/15/25, 2:34 PM

Locally I'm getting:
"✘ [ERROR] An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it."

but it runs anyway, maybe that is the problem?

alex (he/him)•4/15/25, 2:43 PM

Really need a way to limit max concurrency per workflow level. I want some workflows to run 200 in parallel while others only 10. Additionally it would be amazing if workflows can be a queue consumer directly, e.g. take 10 from queue when those 10 are done, take another set of 10.. Any update what is planned and timeline? Also if anyone has an idea how to implement such think today with maybe a workaround, would love to hear that too!

KKuririn Locally I'm getting: "✘ [ERROR] An RPC stub was not disposed properly. You must...

boop•4/15/25, 4:15 PM

My workflows give this error locally as well, but no errors when deployed, see No Access for the thread about it, but no resolution

KKuririn My workflow works locally but when deployed I get error status on my steps, but ...

Kuririn•4/15/25, 5:27 PM

the problem was delay: 0 on retries

Boragorn•4/15/25, 6:23 PM

is it possible to conditionally wait for an event?

if (flag === true) await step.waitForEventif (flag === true) await step.waitForEvent

Something like that

Boragorn•4/15/25, 6:24 PM

for regular steps I can do this:

step.do(
        "Conditional step",
        async () => {
          if (!options.flag) return "skipped";
          return execute(this.env, payload);
        },
      );

step.do(
        "Conditional step",
        async () => {
          if (!options.flag) return "skipped";
          return execute(this.env, payload);
        },
      );

Boragorn•4/15/25, 7:27 PM

Woah -- thank you. That makes a lot of sense.

conneo•4/16/25, 3:51 AM

Hi @cloudflare dev , do you have plans to make it possible to jump to another step in the workflow? This should give us a lot more use cases for workflows.

An example:

step 1: sleep
step 2: call some external system to check status
-- when status <> 'done', go back to step 1
-- else when status 'done', continue
step 3: do some processing

Cconneo Hi @cloudflare dev , do you have plans to make it possible to jump to another st...

Hello, I’m Allie!•4/16/25, 3:56 AM

Could you move steps one and two out of the Workflow?

HHello, I’m Allie!Could you move steps one and two out of the Workflow?

conneo•4/16/25, 4:07 AM

Of course we can. But this is only a very simple example. It should be nice to have the whole process in one workflow.
We build also a lot of workflows in N8N, there we could easily connect output to a previous node to re-run parts of a workflow, until a count or a status result matches, then continue.

I am aware that it could lead to 'spaghetti-code', just like VB-script GOTO

But that's up to us developers.
I'm also not sure if it is hard to implement for CF, because the result of previous steps are accessible in next steps.

But perhaps there was already some discussion about this in the CF team and they can share their thoughts on this.

Cconneo Of course we can. But this is only a very simple example. It should be nice to h...

Hello, I’m Allie!•4/16/25, 4:13 AM

Hm… what about
Within a single step, have a while loop, calling step.sleep, and then checking if it is good to continue, then it breaks and returns into the step

HHello, I’m Allie!Hm… what about Within a single step, have a while loop, calling step.sleep, and ...

conneo•4/16/25, 7:18 AM

Ow... I didn't know I could use step.sleep within a step.do. Will try that!

DanGamble•4/16/25, 9:00 AM

import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from "cloudflare:workers";

export class MyWorkflow extends WorkflowEntrypoint<Env, Params> {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    await step.do("my first step", async () => {})
  }
}

async function mySharedStepBetweenWorkflows (step: WorkflowStep) {
  await step.do("my shared step", async () => {})
}

import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from "cloudflare:workers";

export class MyWorkflow extends WorkflowEntrypoint<Env, Params> {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    await step.do("my first step", async () => {})
  }
}

async function mySharedStepBetweenWorkflows (step: WorkflowStep) {
  await step.do("my shared step", async () => {})
}

Is the mySharedStepBetweenWorkflowsmySharedStepBetweenWorkflows a valid way to have steps be defined in a Workflow?

DanGamble•4/16/25, 9:01 AM

This does work, I'm just wondering if it breaks any "rules" of Workflows

DDanGamble ``` import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from "cloudflare:...

Matt Silverlock•4/16/25, 1:29 PM

Nothing inherently wrong. Just a function. But I don’t see you returning the state within the Workflow’s run method - it might be clearer to instead have await step.do(name, mySharedFunc)await step.do(name, mySharedFunc)

so that it’s the callback

Matt Silverlock•4/16/25, 1:29 PM

Easier to follow and reason about when looking at your workflow.

MMatt Silverlock Nothing inherently wrong. Just a function. But I don’t see you returning the sta...

DanGamble•4/16/25, 1:53 PM

Fair point. Do you think this would make sense if I have multiple steps in the shared function as well? I quite often have multiple steps in the shared functions and I know there is no issues with steps in steps

DDanGamble Fair point. Do you think this would make sense if I have multiple steps in the s...

Matt Silverlock•4/16/25, 4:10 PM

Totally fine.

MMatt Silverlock How are you solving this today/elsewhere? What requires these Workflows to be ti...

hugo martins•4/16/25, 6:05 PM

We could put everything into one workflow, but that would make observability and maintenance difficult for the different teams. On AWS, I handle this by using an SNS topic that sends messages to separate SQS queues, each processed by its own Lambda function.

Marco Aleixo•4/17/25, 10:17 PM

How is this possible?
A 19 minutes step but the timeout is 1 minute

MMarco Aleixo How is this possible? A 19 minutes step but the timeout is 1 minute

Marco Aleixo•4/17/25, 10:31 PM

I stopped the workflow and stated again and the step is now unstuck and finished like in 15 seconds
Definitely a bug on Cloudflare side

"You can set your own instance ID" - OK that is not clear from the docs and examples. I think all th

Similar Threads

Similar Threads

Similar Threads