Does worklows have any special consideration for `waitForEvent` in terms of promises? I have seen

Does worklows have any special consideration for

waitForEvent

waitForEvent

in terms of promises?

I have seen examples using a

Promise.race

Promise.race

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

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

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

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

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.

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.

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

Put another way: everything is a Worker.

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

fforresOP•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
```
(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...

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

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

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

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

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

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

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

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

you mean

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

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

how long do you need it to be?

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

i mean

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

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

, that's where it was throwing the error

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?

FFocux and i was using a third-party UUID as the type, so it would be good if it were a...

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

OK, let us go fix. What works - like 65 bytes? 100 bytes? (the larger the ID the less your event payload, since they share the same underlying RPC limit)

Focux•4/22/25, 9:17 PM

i think 100 bytes would be perfect, and if possible, a more helpful error message

FFocux i think 100 bytes would be perfect, and if possible, a more helpful error messag...

Matt Silverlock•4/22/25, 9:27 PM

OK, let me chat w/ team - have some other stuff we need to solve but we try to avoid holding back quick wins like this

BiffBaffBoff•4/23/25, 1:14 PM

If I have a cloudflare worker using nuxt, is it also possible to have workflows in the same worker? If so, how do I achieve this because the main script is generated after build, so how would I export my workflow from it?

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

I'm experiencing some cases where new workflow instances are being created and remain in the

queued

queued

status forever

fredviken•4/24/25, 11:15 AM

When using worker environments (e.g. test, prod) should the workflows have different names for each envrionment? like e.g my-workflow-test and my-workflow-prod? or can they have they use the same name?

MMatt Silverlock I like to say: Workflows are just code. Call steps conditionally, use Promise.al...

Sam•4/24/25, 2:44 PM

Can you stop the whole workflow like this rather than having to run a repetitive check inside every subsequent step?

step.do () => {
return { stopWorkflow: true }
}

if(stopWorkflow) return;

step.do () => {
// some other step code that will never execute if stopWorkflow did an early return above
}

step.do () => {
// another step here that will never execute if stop workflow did early return
}

SSam Can you stop the whole workflow like this rather than having to run a repetitive...

Matt Silverlock•4/24/25, 3:25 PM

Throw a

NonRetryableError

NonRetryableError

https://developers.cloudflare.com/workflows/build/workers-api/#nonretryableerror

Cloudflare Docs

Workers API · Cloudflare Workflows docs

This guide details the Workflows API within Cloudflare Workers, including methods, types, and usage examples.

MMatt Silverlock Throw a `NonRetryableError` - https://developers.cloudflare.com/workflows/build/...

Sam•4/24/25, 3:33 PM

Thank you Matt!

kchro3•4/24/25, 8:32 PM

We had a workflow that was triggered by a Worker's cron schedule, but even after we removed the cron schedule in the Worker and removed the workflow configuration in wrangler, we're still seeing that the workflow is getting triggered.

Any idea what could be happening?

kchro3•4/24/25, 8:33 PM

I don't see any APIs for deactivating a workflow, too...

kchro3•4/24/25, 8:42 PM

I think I figured it out, we didn't remove the cron trigger in the wrangler.toml, so I guess it's still able to call the dead endpoint? Not sure how that's possible

andifined.dev•4/25/25, 11:50 AM

Hello! I hope you're all doing well!

I'm having an issue with Astro and Cloudflare Workers. My goal is to integrate a workflow within my Astro app, but I'm encountering the following build error:

Worker "workflows:generate-dataset"'s binding "USER_WORKFLOW" refers to service "core:user:web" with a named entrypoint "GenerateDataset", but "core:user:web" has no such named entrypoint.
08:05:33 [ERROR] [@astrojs/cloudflare]

I've defined my workflow within a file in a custom directory, and I suspect that the workflow isn't being bundled into the dist/index.js as declared in wrangler.jsonc.

Does anyone know what I might be missing here? Any help would be greatly appreciated!

This is my astro configuration:
astro.config.mjs
// @ts-check
import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';
import tailwindcss from '@tailwindcss/vite';
import preact from '@astrojs/preact';
import path from 'path';

// https://astro.build/config
export default defineConfig({
output: 'server',
adapter: cloudflare({
platformProxy: {
enabled: true
}
}),
vite: {
plugins: [tailwindcss()],
resolve: {
alias: {
'@': path.resolve('./src'),
'@components': path.resolve('./src/components'),
'@layouts': path.resolve('./src/layouts'),
'@stores': path.resolve('./src/stores'),
'@db': path.resolve('./db'),
'@utils': path.resolve('./utils'),
}
}
},
integrations: [preact()],
});

If you need more information, please let me know!

William•4/25/25, 1:11 PM

Hello my friends, I am using workflows to do async tasks. I call API of my AI provider using fetch, and my API provider did not using Cloudflare as proxy. But I am seeing HTTP 524 response after 100 secnds, I wonder if the subrequests in workflows have default 100 seconds timeout?

MMatt Silverlock If you are mixing the dashboard + wrangler you can run into conditions like this...

Jadugar_Jaggu•4/26/25, 11:30 AM

Hey Matt, did your team fixed it? as I am still facing this issue, we are primarily using vars for changing behavior of our code frequently, and every time I am updating vars from dashboard it removs existing workflow bindings. this behavior is only for workflow bindings for now and not for other products like r2, kv etc.

I hope you will fix it, cause its breaking the application

zhawtof•4/27/25, 2:54 AM

Our team has been discussing how state works in Workflows and this is our understanding:

If at any point, a workflow step fails, our understanding is that it restarts the entire workflow from the beginning. HOWEVER, any functions that are run with

steps.do

steps.do

pulls the data from a cache that Cloudflare has set up.

Therefore if you do the following:

const a = fna()
const b = step.do("fnb", fnb())
const c = fnc(b)
const d = step.do("fnd", fnd(a,b,c))

const a = fna()
const b = step.do("fnb", fnb())
const c = fnc(b)
const d = step.do("fnd", fnd(a,b,c))

fnd

fnd

fails, the following will happen:

```
fna
```
```
fna
```
and
```
fnc
```
```
fnc
```
will both rerun. They better be idempotent.
```
fnb
```
```
fnb
```
will not rerun because it was pulled from the workflow cache.
```
fnd
```
```
fnd
```
will still have access to a, b, and c but a and c are fresh data whereas b was pulled from cache.

I think this has confused a lot of people I've spoken with so, I want to make sure my understanding is right, and it would be amazing to include some examples where functions are NOT running in steps inside of workflows so that other people can grasp this concept as well. Thanks.

Zzhawtof Our team has been discussing how state works in Workflows and this is our unders...

Matt Silverlock•4/27/25, 10:45 PM

https://developers.cloudflare.com/workflows/build/rules-of-workflows/#do-not-rely-on-state-outside-of-a-step covers this (as do examples on the rest of the page re: idempotency). What’s missing?

Cloudflare Docs

Rules of Workflows · Cloudflare Workflows docs

A Workflow contains one or more steps. Each step is a self-contained, individually retriable component of a Workflow. Steps may emit (optional) state that allows a Workflow to persist and continue from that step, even if a Workflow fails due to a network or infrastructure issue.

SSaket Hi, I am new to workflows. My team is building a new application from the bottom...

Matt Silverlock•4/27/25, 10:46 PM

For many folks: yes, it can.

MMatt Silverlock https://developers.cloudflare.com/workflows/build/rules-of-workflows/#do-not-rel...

scook•4/28/25, 4:20 AM

IMO the docs should very clearly spell out what kind of code is allowed outside of steps and why. If you explain some of the behind-the-scenes of how workflows work (e.g. it re-executes the entire workflow while using cached state of already-executed steps), that will clarify a lot to the readers. It helped me a lot once I understood the why behind the rules, instead of simply being told the rules.

ddsgadget•4/28/25, 11:13 AM

Hi, we've been using workflow for awhile and they work great. However, today we created a new workflow and whenever it runs we get an RPC error in cloudflare dashboard (origin: rpc, trigger: default.run) . We have never seen an RPC call after a workflow is executed, so we are not even sure why there is an RPC call. Also, there is no explanation of what the error actually is on the run. This only happens with the new Workflow. None of the other workflows generate any type of RPC call or error. Are workflow runs supposed to generate an RPC call? And if so, why don't we see it with other workflows and how do we figure out what the error is? Also, i should mention that the workflow that triggers an RPC error itself runs fine and has no errors, so again this is very strange. There is an RPC error generated by teh workflow, but the workflow runs fine? UPDATE: Actually in looking thru our logs over the last 24 hours, we do see other workflows generate errors on the "run" stage in an RPC, the entry point being our workflow. However, all of these workflows execute perfectly fine and we have no issues. So what is the RPC error exactly? Interestingly, workflows called from Durable Objects do not show any errors like this, but workflows called in normal workers do?

Dddsgadget Hi, we've been using workflow for awhile and they work great. However, today we ...

ddsgadget•4/28/25, 8:02 PM

BTW, I noticed that if you terminate the workflow at the last step like the code below, there is no RPC error on the defaut.run of the workflow. However, when you don't terminate the workflow and/or you return something in the final step, you get an error in the rpc for the workflow default.run. As per above, even with the error, the workflows work fine. So i think this is a bug in how worfklows are called and terminated. I guess there is currently no way to tell the system that the workflow has ended, and that causes an error? Unless you terminate it? Not really sure. Anyhow, we now just terminate all workflows at the final step to remvoe this error. let instance = await this.env.<WORKFLOW>.get(instanceId);
await instance.terminate();

andy•4/29/25, 9:10 AM

Hi, perhaps this is a question already answered in the docs but I can't see it.

How can we see the console logs from a workflow.
i.e. if we have some run like this, how can I see the console logs.

  async run(context: WorkflowEvent<MyParams>, step: WorkflowStep): Promise<void> {
    const workflowId = context.instanceId;
    const params = context.payload;
    console.log(`Workflow ${workflowId} started with params:`, [...Object.keys(params)]);

    try {

      // Step 1: Example
      const processedData = await step.do('process-data', async () => {
        console.log(`[${workflowId}] Step 1: Processing data...`);
        
        // Simulate work - replace with actual logic
        await new Promise(resolve => setTimeout(resolve, 1000)); // Simulate delay
        console.log(`[${workflowId}] Step 1: Processing complete.`);
        return true;
      });

  async run(context: WorkflowEvent<MyParams>, step: WorkflowStep): Promise<void> {
    const workflowId = context.instanceId;
    const params = context.payload;
    console.log(`Workflow ${workflowId} started with params:`, [...Object.keys(params)]);

    try {

      // Step 1: Example
      const processedData = await step.do('process-data', async () => {
        console.log(`[${workflowId}] Step 1: Processing data...`);
        
        // Simulate work - replace with actual logic
        await new Promise(resolve => setTimeout(resolve, 1000)); // Simulate delay
        console.log(`[${workflowId}] Step 1: Processing complete.`);
        return true;
      });

I have tried

wrangler workflows instances describe

wrangler workflows instances describe

and I can't see the log messages there.
I have tried looking at the logs of the bound worker and I can't see the log messages there either.

ddsgadget•4/29/25, 9:19 AM

@andy Yeah I asked this same question a few days ago. As far as I can tell, you can't see the console.log anywhere. Hopefully they will implement something where you can see the console.log on each step in the admin dashboard for workflows, but right now, you can't see a thing.

Dddsgadget @andy Yeah I asked this same question a few days ago. As far as I can tell, you ...

andy•4/29/25, 9:20 AM

thanks! At least I don't need to waste time looking

Isak•4/29/25, 5:03 PM

Hello @Matt Silverlock, sorry for pinging you. Could you provide some guidance on this issue? workflowslocal dev not working

Tim Lonsdale•4/29/25, 7:05 PM

Hi chaps, relatively new to workflows. We have a relatively weird use-case in mind. Each user of our software will have "work/jobs" enqueued that will need to be processed. The caveat is that each bit of work must run sequentially. I was thinking that this could be accomplished by having a long/infinitely-long running workflow for each user that sleeps for x seconds, wakes and checks for work - processes it if it exists - otherwise goes back to sleep (repeat forever). Would something like that be achievable with workflows? With CF, we only pay for compute time so I wouldn't have thought the costs of this would be too onerous vs. using something like Lambda

TTim Lonsdale Hi chaps, relatively new to workflows. We have a relatively weird use-case in mi...

boop•4/29/25, 8:49 PM

You could use a cron trigger on a worker that checks for work, and then send that result to workflows
https://developers.cloudflare.com/workers/configuration/cron-triggers/

Bboop You could use a cron trigger on a worker that checks for work, and then send tha...

Isaac Hinman•4/29/25, 9:53 PM

But the minimum cron interval would be 1 minute, no? We were hoping for something on the order of seconds

IIsaac Hinman But the minimum cron interval would be 1 minute, no? We were hoping for somethin...

boop•4/29/25, 10:19 PM

Durable Objects with alarms that call a worker every x seconds? Is your sequential requirement per-user or for the entire work/jobs queue?

Does worklows have any special consideration for `waitForEvent` in terms of promises? I have seen

Similar Threads

Similar Threads

Similar Threads