Is this released or coming in the future? "When creating a Workflow instance, you can set a shorter

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

M

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

Coming soon.

A

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

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

Yep, the limit is the same as workers

A

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

Thanks!

S

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

How can we disable retries? Is is sufficient to set

retries

retries

retries

retries to

?

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...

J

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

you have to configure it for every step

M

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

When we will be able to delete Workflows?

C

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?

K

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)

K

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?

A

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...

B

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 ...

K

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

the problem was delay: 0 on retries

B

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

is it possible to conditionally wait for an event?

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

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

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

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

Something like that

B

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);
        },
      );

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);
        },
      );

B

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

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

C

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...

H

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?

C

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...

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 ...

C

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

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

D

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 () => {})
}

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

mySharedStepBetweenWorkflows

mySharedStepBetweenWorkflows

mySharedStepBetweenWorkflows

mySharedStepBetweenWorkflows a valid way to have steps be defined in a Workflow?

D

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:...

M

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)

await step.do(name, mySharedFunc)

await step.do(name, mySharedFunc)

so that it’s the callback

M

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...

D

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...

M

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...

H

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.

M

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

M

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

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

M

Matt Silverlock•4/18/25, 10:54 AM

What is your account ID?

MMatt Silverlock What is your account ID?

M

Marco Aleixo•4/18/25, 11:51 AM

15685db9d45942a2040643bb0a0ccec1

MMarco Aleixo 15685db9d45942a2040643bb0a0ccec1

M

Matt Silverlock•4/18/25, 12:32 PM

OK. Looking into.

F

fforres•4/18/25, 3:24 PM

I haven't had any issues so far but also haven't played with hibernation much so far

... but I want to know if my assumption is correct.

Rules of workflows stating that you should not depend on state define solely outside of a step, and workflows can use outputs of steps across their execution.

So... would somethint like this be OK?

export class MyWorkflow extends WorkflowEntrypoint {
    let someState = await step.do('define-state', async() => ....)
    
    while (x of someState) {
        await step.do('some execution', async() => ...)    
        step.sleep('xxx', '1 day') // or enough time to hibernate for example
        someState = await step.do('re-define state', async() => ...) // this sets someState to false
    }

    await step.do('we end the flow', async () => ...)
}

export class MyWorkflow extends WorkflowEntrypoint {
    let someState = await step.do('define-state', async() => ....)
    
    while (x of someState) {
        await step.do('some execution', async() => ...)    
        step.sleep('xxx', '1 day') // or enough time to hibernate for example
        someState = await step.do('re-define state', async() => ...) // this sets someState to false
    }

    await step.do('we end the flow', async () => ...)
}

export class MyWorkflow extends WorkflowEntrypoint {
    let someState = await step.do('define-state', async() => ....)
    
    while (x of someState) {
        await step.do('some execution', async() => ...)    
        step.sleep('xxx', '1 day') // or enough time to hibernate for example
        someState = await step.do('re-define state', async() => ...) // this sets someState to false
    }

    await step.do('we end the flow', async () => ...)
}

export class MyWorkflow extends WorkflowEntrypoint {
    let someState = await step.do('define-state', async() => ....)
    
    while (x of someState) {
        await step.do('some execution', async() => ...)    
        step.sleep('xxx', '1 day') // or enough time to hibernate for example
        someState = await step.do('re-define state', async() => ...) // this sets someState to false
    }

    await step.do('we end the flow', async () => ...)
}

B

ByteBeast•4/19/25, 1:59 PM

Can I get workflow instance id in workflow itself? I want workflow instance id in step of that workflow.

BByteBeast Can I get workflow instance id in workflow itself? I want workflow instance id i...

Z

zegevlier•4/19/25, 3:01 PM

You should be able to with the

event.instanceId

event.instanceId

event.instanceId

event.instanceId (https://developers.cloudflare.com/workflows/build/workers-api/#workflowevent)

B

ByteBeast•4/19/25, 4:05 PM

@zegevlier Worked. Thank you!

H

hugo martins•4/19/25, 7:01 PM

is there any plan in the future to be able to rate limit a step in a workflow (across workflow invocations )? a lot of AI endpoint are rate limited

C

Craig•4/20/25, 8:22 AM

Hey guys, even though the workflow can be executed manually from the Cloudflare Dashboard, I couldn't run it using the worker's scheduled() function. Also, each scheduled event shows 0 ms time. Am I doing something wrong here?

export default {
  fetch: app.fetch,
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    env.PROCESS_NOTION_STATUS.create();
    env.PROCESS_NOTION_RELEASE.create();
  },
};

export default {
  fetch: app.fetch,
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    env.PROCESS_NOTION_STATUS.create();
    env.PROCESS_NOTION_RELEASE.create();
  },
};

export default {
  fetch: app.fetch,
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    env.PROCESS_NOTION_STATUS.create();
    env.PROCESS_NOTION_RELEASE.create();
  },
};

export default {
  fetch: app.fetch,
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    env.PROCESS_NOTION_STATUS.create();
    env.PROCESS_NOTION_RELEASE.create();
  },
};

M

mattderron•4/20/25, 4:27 PM

Hello, I've been building my first workflows, and it looks like everything is working in all of the steps and they complete fine. But every time my workflow runs (whether by cron trigger or manual trigger) I get a RPC run error in the logs that looks like this. Is there an issue with how I'm executing steps or is this known behavior?

Screenshot_2025-04-20_at_11.24.21_AM.png

M

Matt Silverlock•4/20/25, 9:11 PM

Known issue! Working on fixing.

MMatt Silverlock Known issue! Working on fixing.

M

mattderron•4/20/25, 10:21 PM

Awesome, thanks!

D

ddsgadget•4/21/25, 1:34 AM

If I console.log something in a step in a workflow, where does that message show up? I look in the cloudflare dashboard and dont see any consoles for our workflows. We have observability turned on and I can see console for regular worker functions and durable objects, but nothing from the workflow steps. where do these show up? BTW, if possible it would be great if the console logs show in the workflow dashboard for each step. Right now, you only see the result of the step in the dashboard, as far as I can teell.

I

ItsWendell•4/21/25, 1:24 PM

I got something odd, where some of my workflow runs are suddenly in a "waiting" state, even though I didn't pause them or anything. I've checked and they're also not executing anything since I keep track of progress (even within steps) in a database. New workflow runs are running properly.

I

ItsWendell•4/21/25, 1:40 PM

Also, is it possible to get a callback within the workflow itself when the workflow run fails? Or could I just put the entire

Workflow.run()

Workflow.run()

Workflow.run()

Workflow.run() function ina try / catch block?

IItsWendell Also, is it possible to get a callback within the workflow itself when the workf...

S

Seekerdasbatatas•4/21/25, 3:36 PM

workflows are just JS, so you can do the latter

I

IsakOP•4/21/25, 4:40 PM

Do Workflows not support

BigInt

BigInt

BigInt

BigInt?

Uncaught (in promise) TypeError: Do not know how to serialize a BigInt

Uncaught (in promise) TypeError: Do not know how to serialize a BigInt

Uncaught (in promise) TypeError: Do not know how to serialize a BigInt

Uncaught (in promise) TypeError: Do not know how to serialize a BigInt

F

fforres•4/21/25, 11:45 PM

Does worklows have any special consideration for

waitForEvent

waitForEvent

waitForEvent

waitForEvent in terms of promises?

I have seen examples using a

Promise.race

Promise.race

Promise.race

Promise.race like

let value = Promise.race([
  step.waitForEvent("payment success", { type: "payment-success-webhook", timeout: "4 hours" ),
  step.waitForEvent("payment failure", { type: "payment-failure-webhook", timeout: "4 hours" ),
])

let value = Promise.race([
  step.waitForEvent("payment success", { type: "payment-success-webhook", timeout: "4 hours" ),
  step.waitForEvent("payment failure", { type: "payment-failure-webhook", timeout: "4 hours" ),
])

let value = Promise.race([
  step.waitForEvent("payment success", { type: "payment-success-webhook", timeout: "4 hours" ),
  step.waitForEvent("payment failure", { type: "payment-failure-webhook", timeout: "4 hours" ),
])

let value = Promise.race([
  step.waitForEvent("payment success", { type: "payment-success-webhook", timeout: "4 hours" ),
  step.waitForEvent("payment failure", { type: "payment-failure-webhook", timeout: "4 hours" ),
])

So before testing... Wondering if a

Promise.all

Promise.all

Promise.all

Promise.all would also work?

const longArray: { id: string, data: any }[] = [
  /* imagine a lot of things here */ 
  ...
]

const bunchOfWaitForEvnts = longArray.map(item => step.waitForEvent("sub-workflow", { type: `id-${item.id}`, timeout: "4 hours" ))
const aggregatedResponses = Promise.all(bunchOfWaitForEvnts)

await step.do('do-more-stuff-with-aggregated-responses', async () => { /* */})

const longArray: { id: string, data: any }[] = [
  /* imagine a lot of things here */ 
  ...
]

const bunchOfWaitForEvnts = longArray.map(item => step.waitForEvent("sub-workflow", { type: `id-${item.id}`, timeout: "4 hours" ))
const aggregatedResponses = Promise.all(bunchOfWaitForEvnts)

await step.do('do-more-stuff-with-aggregated-responses', async () => { /* */})

const longArray: { id: string, data: any }[] = [
  /* imagine a lot of things here */ 
  ...
]

const bunchOfWaitForEvnts = longArray.map(item => step.waitForEvent("sub-workflow", { type: `id-${item.id}`, timeout: "4 hours" ))
const aggregatedResponses = Promise.all(bunchOfWaitForEvnts)

await step.do('do-more-stuff-with-aggregated-responses', async () => { /* */})

const longArray: { id: string, data: any }[] = [
  /* imagine a lot of things here */ 
  ...
]

const bunchOfWaitForEvnts = longArray.map(item => step.waitForEvent("sub-workflow", { type: `id-${item.id}`, timeout: "4 hours" ))
const aggregatedResponses = Promise.all(bunchOfWaitForEvnts)

await step.do('do-more-stuff-with-aggregated-responses', async () => { /* */})

I'm trying to simplify some flows. Like:

if I could wait for 20 events based on
```
bunchOfWaitForEvnts
```
bunchOfWaitForEvnts
```
bunchOfWaitForEvnts
```
bunchOfWaitForEvnts
Trigger 20 workflows based on
```
bunchOfWaitForEvnts
```
bunchOfWaitForEvnts
```
bunchOfWaitForEvnts
```
bunchOfWaitForEvnts
Each workflow calls
```
instance.sendEvent()
```
instance.sendEvent()
```
instance.sendEvent()
```
instance.sendEvent()
with their ID.
Then it occurred to me that this could also help with the sub-request limit?

Is this released or coming in the future? "When creating a Workflow instance, you can set a shorter

Similar Threads

Similar Threads

Similar Threads