Of course we can. But this is only a very simple example. It should be nice to have the whole proces

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

H

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

conneoOP•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

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)

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

(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()

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

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

Do Workflows not support

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

F

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

Does worklows have any special consideration for

waitForEvent

waitForEvent

in terms of promises?

I have seen examples using a

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

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
```
Trigger 20 workflows based on
```
bunchOfWaitForEvnts
```
```
bunchOfWaitForEvnts
```
Each workflow calls
```
instance.sendEvent()
```
```
instance.sendEvent()
```
with their ID.
Then it occurred to me that this could also help with the sub-request limit?

DDivinitii I'd like to replace some of my Durable Object logic with Workflows, but it seems...

B

boop•4/22/25, 8:33 AM

You could push to a queue and then batch to workflows in your consumer

Ffforres Does worklows have any special consideration for `waitForEvent` in terms of prom...

M

Matt Silverlock•4/22/25, 12:47 PM

Promise.all

Promise.all

works - we don’t change how the standard promise handling works.

sendEvent

sendEvent

is still a sub-request though.

DDivinitii I'd like to replace some of my Durable Object logic with Workflows, but it seems...

M

Matt Silverlock•4/22/25, 12:48 PM

What are you trying to achieve - e.g. what is the task/actual problem you are solving? Do you need the durable execution + step tracking of a workflow?

JJonathan Lister Parsons Can I sanity check something with my mental model? Should I think of a Workflow ...

M

Matt Silverlock•4/22/25, 1:37 PM

It’s just a Worker. The “script” (Worker) can expose whatever it needs to: a fetch handler, a queue handler, a workflow, a DO, etc.

M

Matt Silverlock•4/22/25, 1:38 PM

My own Agent project is a Fetch handler (for handling requests) -> an Agent (DO underneath) + kicks off Workflows. All one project.

M

Matt Silverlock•4/22/25, 1:38 PM

Put another way: everything is a Worker.

B

Bogdan•4/22/25, 2:25 PM

hey, how many subrequests does the cloudflare workflow can make? worker can do 1000 subrequests, but if I use workflow, each step can do 1k of subrequets, or the entire workflow limited by this amount?

MMatt Silverlock `Promise.all` works - we don’t change how the standard promise handling works. `...

F

fforres•4/22/25, 3:28 PM

Gotcha

sendEvent
sendEvent
is still a sub-request though

Like from the perspective of the sender right? (I imagine I mean... but just in case?)

My thought process is that Instead of having a workflow:

Trigger 1000 sub requests
- Sub-request doing a lot of db-calls/other-workflows/etc, (Likely reaching sub-request limits)
Wait for 1000 answers
Continue execution

That workflow could instead:

Trigger 1000 workflows, (and a not await for their responses)
- Worflows being able to do up to 1000 sub-requests on their own.
Promise.all/await for 1000 events (with unique IDs)
Have every one of those other workflows call a
```
.sendEvent
```
.sendEvent
```
.sendEvent
```
.sendEvent
(with unique Ids)
Continue execution

Tldr, main question is that a "sub" workflow request could count towards a sub-request calculation. or are they separated?

Ffforres Gotcha 😄 > `sendEvent` is still a sub-request though Like from the perspecti...

M

Matt Silverlock•4/22/25, 3:41 PM

Sender, yep. Any "API call" is a sub-request.

JJonathan Lister Parsons Ok great, so one Worker can export a fetch handler as well as define multiple Wo...

M

Matt Silverlock•4/22/25, 3:41 PM

Yep. It can all be in separate files, or even further. It's just code!

F

Focux•4/22/25, 5:07 PM

FYI, I just spent half a day trying to figure out why sending events was throwing this error

Error: (workflow.invalid_event_type) Provided event type is invalid

Error: (workflow.invalid_event_type) Provided event type is invalid

Error: (workflow.invalid_event_type) Provided event type is invalid

Error: (workflow.invalid_event_type) Provided event type is invalid, and it was because it doesn't work with long-ish event names. I was using a UUID as the event name, and it wasn't working...

F

Focux•4/22/25, 5:08 PM

Not sure whether this is a bug or it is intended, if the latter, it would be good to add it to the docs

F

fredviken•4/22/25, 5:23 PM

I got cross-script calls to work locally using the "-c" option, but not when running them with separate dev commands. Is this a known limitation? If so it would be nice if it was mentioned in the docs

FFocux FYI, I just spent half a day trying to figure out why sending events was throwin...

M

Matt Silverlock•4/22/25, 6:51 PM

you mean

step.waitForEvent("name", { type: "here" })

step.waitForEvent("name", { type: "here" })

step.waitForEvent("name", { type: "here" })

step.waitForEvent("name", { type: "here" })

how long do you need it to be?

F

Focux•4/22/25, 6:55 PM

i mean

instance.sendEvent({ type: "here" })

instance.sendEvent({ type: "here" })

instance.sendEvent({ type: "here" })

instance.sendEvent({ type: "here" }), that's where it was throwing the error

F

Focux•4/22/25, 6:56 PM

and i was using a third-party UUID as the type, so it would be good if it were a bit longer than a normal uuid?

Of course we can. But this is only a very simple example. It should be nice to have the whole proces

Similar Threads