Any plans to add a way to wait for an outside event? an alternative right now would be to make a nor

Any plans to add a way to wait for an outside event? an alternative right now would be to make a normal step with a very high retry limit and a constant backoff and fail it everytime if some condition isn't met, but that seems wasteful.

Another hack to achieve this is to pause the workflow once it reaches a certain step, then resume it once some condition is met and a value is set somewhere so that the workflow can retrieve that value and continue its execution.

But some API like this would be way more efficient with a far better DX:

// Inside the workflow (Maybe it could have some timeout option to fail the workflow if the event never comes within a timeframe)
const payload = await step.waitFor("event_name", "10 minutes")

// And outside the workflow, having the ability to check what event is being waited on would be great to avoid race conditions leading to stuck workflows
if("event_name" === await workflowInstance.waitedOnEvent()){
    await workflowInstance.send("event_name", /* Optional payload */)
}

// And for events that we just want to queue for whenever they come up and don't care that the workflow will start waiting for them we can simply send them
// This would be useful for cases where multiple webhook events that we are interested in might come out of order so that we wouldn't need to care about when we send them to the workflow
await workflowInstance.send("some_event", /* Optional payload */)

// Inside the workflow (Maybe it could have some timeout option to fail the workflow if the event never comes within a timeframe)
const payload = await step.waitFor("event_name", "10 minutes")

// And outside the workflow, having the ability to check what event is being waited on would be great to avoid race conditions leading to stuck workflows
if("event_name" === await workflowInstance.waitedOnEvent()){
    await workflowInstance.send("event_name", /* Optional payload */)
}

// And for events that we just want to queue for whenever they come up and don't care that the workflow will start waiting for them we can simply send them
// This would be useful for cases where multiple webhook events that we are interested in might come out of order so that we wouldn't need to care about when we send them to the workflow
await workflowInstance.send("some_event", /* Optional payload */)

// Inside the workflow (Maybe it could have some timeout option to fail the workflow if the event never comes within a timeframe)
const payload = await step.waitFor("event_name", "10 minutes")

// And outside the workflow, having the ability to check what event is being waited on would be great to avoid race conditions leading to stuck workflows
if("event_name" === await workflowInstance.waitedOnEvent()){
    await workflowInstance.send("event_name", /* Optional payload */)
}

// And for events that we just want to queue for whenever they come up and don't care that the workflow will start waiting for them we can simply send them
// This would be useful for cases where multiple webhook events that we are interested in might come out of order so that we wouldn't need to care about when we send them to the workflow
await workflowInstance.send("some_event", /* Optional payload */)

// Inside the workflow (Maybe it could have some timeout option to fail the workflow if the event never comes within a timeframe)
const payload = await step.waitFor("event_name", "10 minutes")

// And outside the workflow, having the ability to check what event is being waited on would be great to avoid race conditions leading to stuck workflows
if("event_name" === await workflowInstance.waitedOnEvent()){
    await workflowInstance.send("event_name", /* Optional payload */)
}

// And for events that we just want to queue for whenever they come up and don't care that the workflow will start waiting for them we can simply send them
// This would be useful for cases where multiple webhook events that we are interested in might come out of order so that we wouldn't need to care about when we send them to the workflow
await workflowInstance.send("some_event", /* Optional payload */)

alex (he/him)•3/8/25, 6:00 AM

What is the correct way to bind a workflow to another Worker, so that I can trigger it from multiple workers? Is a service binding with RPC calls the only way, I thought it would be possible to bind it natively, so I can use

.create()

.create()

.status()

.status()

.terminate()

.terminate()

from multiple workers?

alex (he/him)•3/8/25, 6:02 AM

At least this sentence makes me think it should be possible:

to call into Workflows from other Workers scripts.

to call into Workflows from other Workers scripts.

alex (he/him)•3/8/25, 6:19 AM

Found this https://developers.cloudflare.com/workflows/build/workers-api/#cross-script-calls should be what I want, however now I get this error, which others also seem to get for other setups, but my setupis worker-to-worker. I don't have

USER_WORKFLOW

USER_WORKFLOW

at all defined. Talking about local development!

✘ [ERROR] Worker "workflows:repguide-workflows-ai-rag"'s binding "USER_WORKFLOW" refers to a service "core:user:repguide-workflows", but no such service is defined.

✘ [ERROR] Worker "workflows:repguide-workflows-ai-rag"'s binding "USER_WORKFLOW" refers to a service "core:user:repguide-workflows", but no such service is defined.

alex (he/him)•3/8/25, 6:28 AM

Looks like I'm not the only one having the issue when running

dev

dev

workflows
workflows

alex (he/him)•3/8/25, 6:37 AM

Just figured out it works when starting multiple workers with the same

wrangler dev

wrangler dev

command

wrangler dev -c apps/rest/wrangler.jsonc -c apps/workflows/wrangler.jsonc -c apps/orm/wrangler.jsonc

wrangler dev -c apps/rest/wrangler.jsonc -c apps/workflows/wrangler.jsonc -c apps/orm/wrangler.jsonc

But now I have the issue that I have multiple workers with an entry point, and I need to write a handler locally like described here: wrangler

YYassine Any plans to add a way to wait for an outside event? an alternative right now wo...

Ashley•3/8/25, 9:53 AM

It’s on the roadmap IIRC, but for now you can do what you said or use something like https://github.com/apeacock1991/workflows-wait-for-action (uses Durable Objects) to pause/resume when something happens outside your Workflow

GitHub

GitHub - apeacock1991/workflows-wait-for-action

Contribute to apeacock1991/workflows-wait-for-action development by creating an account on GitHub.

alex (he/him)•3/8/25, 4:42 PM

Can we limit concurrency of workflows when running locally with

wrangler dev

wrangler dev

alex (he/him)•3/8/25, 4:58 PM

Any plan to increase the 1MB limit for step output and state? I would love to see at least 10MB ,maybe even 100MB

Aalex (he/him)Any plan to increase the 1MB limit for step output and state? I would love to se...

DaniFoldi•3/8/25, 8:23 PM

I think for those sizes the recommendation will be to use R2 to store the state - you can have it in the same step where it's generated so if saving to R2 fails it regenerates the contents too

DDaniFoldi I think for those sizes the recommendation will be to use R2 to store the state ...

alex (he/him)•3/8/25, 9:07 PM

Well we have files stored in R2, but we need those files in multiple steps afterwards, so following the idea that steps should be self-contained and granular, it doesn't feel right to pull files from r2 multiple times inside each step and have that part of the step too, hope my explanation makes sense

ajay | dreamlit.ai•3/10/25, 5:40 PM

Is there a way to specify the placement of the workflows workers? For some reason in my scenario my workers appear to be placed on the opposite coast of my db

alex (he/him)•3/10/25, 8:18 PM

Would it be safe/recommended to use the following code or would that hit any limit?

const a = await this.env.EXTENSION_HANDLER.get('id');
let state = await a.status();
while (state.status !== 'running') {
  state = await a.status();
}

const a = await this.env.EXTENSION_HANDLER.get('id');
let state = await a.status();
while (state.status !== 'running') {
  state = await a.status();
}

alex (he/him)•3/10/25, 8:24 PM

I need to wrap a workflow inside a api handler, so we can send the user response directly when the workflow finishes. I'm aware that this isn't the typical usecase for a workflow, but we don't want to implement our logic twice, once for runtime and the other for background handling. And in theory it would not be any difference if we just let the use wait for it to finish.

Aalex (he/him)Would it be safe/recommended to use the following code or would that hit any lim...

tadhglewis•3/10/25, 11:36 PM

Fetching the status in a loop isn't exactly good. You'd be using CPU + spamming the status - not sure about exact limits though

Aalex (he/him)I need to wrap a workflow inside a api handler, so we can send the user response...

tadhglewis•3/10/25, 11:38 PM

I wouldn't recommend it. Workflows are inherently asynchronous.

At scale, you will eventually run into issues with the user response timing out if the workflow takes longer than expected (whether that's your code or Cloudflare delays).
You need to handle failures from the workflow

tadhglewis•3/10/25, 11:39 PM

but we don't want to implement our logic twice

Why don't you share the workflow logic by abstracting it into a function which can be called by either the Workflow or synchronous endpoint?

Ttadhglewis It doesn't seem like a good fit to me. You're trying to do asynchronous work in ...

tadhglewis•3/10/25, 11:40 PM

related ^

Ttadhglewis > but we don't want to implement our logic twice Why don't you share the workflo...

alex (he/him)•3/11/25, 5:51 AM

Yeah we could try to do that!

alex (he/him)•3/11/25, 5:52 AM

And then use a service binding i suppose?

tadhglewis•3/11/25, 6:47 AM

I was more thinking just a literal JS function that you call - assuming the workflow and endpoint are in the same repo

alex (he/him)•3/11/25, 9:07 AM

There not. We have at least 3 workers interlinked, which need the logic

tadhglewis•3/11/25, 9:31 AM

You could also use an NPM package or workspace if you have a monorepo

sdr•3/11/25, 10:17 PM

I think the workflows index is showing CPU time and not Wall time?

sdr•3/11/25, 10:18 PM

I ran a workflow once it should say about 30s wall time in the aggregate index view

BBiffBaffBoff Thank you, I tried that but I didnt have access to `createInstance`. When I ran ...

flash716•3/12/25, 2:39 AM

Just now saw your response. I was able to get dev Pages and dev Worker using the same dev d1 by pointing the Worker to the Pages wrangler state directory. Here's my "dev" command in my Worker's package.json:

wrangler dev --env dev --port 53769 --persist-to=../web-app/.wrangler/state

wrangler dev --env dev --port 53769 --persist-to=../web-app/.wrangler/state

(This is in a monorepo, but I don't think there's any reason you couldn't point persist-to to a different repo. I would just make sure you keep your wrangler version in sync between the two)

Chris Jayden•3/12/25, 7:01 PM

Any timeline on deleting workflows? My account is become messy and unorganized

adeola13.•3/12/25, 9:13 PM

hello is it a bad practic to trigger different workflows inside of a workflow?

Original message was deleted

adeola13.•3/12/25, 10:36 PM

ah yep that makes sense. Thank you !

Isak•3/12/25, 10:52 PM

Is this a valid pattern for running a workflow indefinitely while also circumventing the subrequest limit? This approach allows the workflow to enter a waiting state and restart with a fresh quota.
Also how does this handle updates to the workflow, and is it billed as a single invocation?

export class HelloWorldWorkflow extends WorkflowEntrypoint {
  async run(_: Readonly<WorkflowEvent<unknown>>, step: WorkflowStep) {
    while (true) {
      try {
        await step.do('fetch data', async () => {
          await fetch('data url')
        })
        await step.sleep('wait untill next data', '5 minutes')
      } catch {
        await step.sleep('handle too many subrequests', '15 minutes')
      }
    }
  }
}

export class HelloWorldWorkflow extends WorkflowEntrypoint {
  async run(_: Readonly<WorkflowEvent<unknown>>, step: WorkflowStep) {
    while (true) {
      try {
        await step.do('fetch data', async () => {
          await fetch('data url')
        })
        await step.sleep('wait untill next data', '5 minutes')
      } catch {
        await step.sleep('handle too many subrequests', '15 minutes')
      }
    }
  }
}

Chris Jayden•3/13/25, 10:17 AM

I vibe coded a simple chrome extension to hide your unused Cloudflare workflows (until archive/delete becomes available).

https://github.com/multiplehats/hide-cloudflare-workflows?t=12323323

GitHub

GitHub - multiplehats/hide-cloudflare-workflows

Contribute to multiplehats/hide-cloudflare-workflows development by creating an account on GitHub.

luiseok•3/13/25, 10:56 AM

I am encountering the following error while creating a Workflow.

DataCloneError:
Could not serialize object of type "InstanceImpl". This type does not support serialization.

DataCloneError:
Could not serialize object of type "InstanceImpl". This type does not support serialization.

Do you have any idea what might be causing this issue? The same problem keeps occurring consistently at the same step in other Workflows as well. For reference, I am also attaching my code—there is no special logic involved; it simply runs another Workflow within the Workflow.

Lluiseok I am encountering the following error while creating a Workflow. ``` DataCloneE...

Matt Silverlock•3/13/25, 11:35 AM

State can only be objects that are Serializable. You’re trying to return an

Instance

Instance

object, which is not (it has methods).

Just return the

id

id

MMatt Silverlock State can only be objects that are Serializable. You’re trying to return an `Ins...

luiseok•3/13/25, 12:21 PM

Thanks Matt. I was able to fix the issue by returning only

id

id

Alex Patterson•3/13/25, 3:30 PM

Can someone confirm that workflows are blocking? With "create" I was expecting they would run in their own service and then later I would poll to see if they have been updated. But in reality they are blocking my API call. I think will probably have to introduce queues as well if this is the case.

// Start workflows
c.env.COVE_WORKFLOW_VIDEO_UPLOAD_STREAM.create({
    params: {
        videoId: id,
    },
});
c.env.COVE_WORKFLOW_VIDEO_TRANSCRIPT.create({
    params: {
        videoId: id,
    },
});

// Start workflows
c.env.COVE_WORKFLOW_VIDEO_UPLOAD_STREAM.create({
    params: {
        videoId: id,
    },
});
c.env.COVE_WORKFLOW_VIDEO_TRANSCRIPT.create({
    params: {
        videoId: id,
    },
});

AAlex Patterson Can someone confirm that workflows are blocking? With "create" I was expecting t...

Aslak Hellesoy•3/13/25, 6:26 PM

They're not blocking. Workflow.create returns a WorkflowInstance - and it returns before the workflow has completed.

Aslak Hellesoy•3/13/25, 6:29 PM

Has anyone managed to get logs from workflows? When a workflow step fails, there is no stack trace in the Cloudflare dashboard - only the error message is displayed.

I've tried to integrate

@sentry/cloudflare

@sentry/cloudflare

, but from what I can tell it only provides high level wrappers for fetch requests and pages - I can't figure out how to make a cloudflare logger instance.

Matt Silverlock•3/14/25, 2:18 AM

Do you have an example? They should show up in logs under the Worker script - if you have

observability.enabled: true

observability.enabled: true

Yuuseiran•3/14/25, 5:04 AM

hey pals. I'm kinda new to workflows, as per the documentation, restarting a workflow via the restart() function is not supported and will throw an error. is there a way to restart an instance? also can i trigger a restart on a errored instance?

nejc•3/14/25, 9:43 AM

Hi all, I have a workflow that accepts 1000 leds for example and then for each lead needs to do two steps and then call callback. Is there a cleaner way to do this flow, because my worry is that things will get mixed around when retries kick in. This is pseudo code:

for (const lead of leads) {
  const result = await Promise.all([step.do('Step 1', async () => {}), step.do('Step 2', async () => {})])

  await step.do('callback', async () => { /* callback with a result */})
}

for (const lead of leads) {
  const result = await Promise.all([step.do('Step 1', async () => {}), step.do('Step 2', async () => {})])

  await step.do('callback', async () => { /* callback with a result */})
}

Murder Chicken•3/14/25, 4:16 PM

Is it possible to trigger a workflow-B from within a workflow-A?

MMurder Chicken Is it possible to trigger a workflow-B from within a workflow-A?

Chris Jayden•3/14/25, 4:29 PM

Yes.

Murder Chicken•3/14/25, 4:32 PM

Interesting, how would that be configured in the wrangler.toml as a binding?

Murder Chicken•3/14/25, 4:45 PM

Because a workflow has a configuration in it's

toml

toml

like this:

[[workflows]]
name = "workflow-a"
binding = "WORKFLOW_A"
class_name = "WorkflowA"

[[workflows]]
name = "workflow-a"
binding = "WORKFLOW_A"
class_name = "WorkflowA"

But if

workflow B

workflow B

needs to have a binding in

workflow A

workflow A

, where does that binding go? Just another

[[workflows]]

[[workflows]]

entry? If so, that seems to fail as it would expect the

class_name

class_name

reference to exist in

workflow A

workflow A

's index.

Kkchro3 Seeing this error: ``` { "$workers": { "diagnosticsChannelEvents": [], ...

rodrigo•3/14/25, 5:23 PM

anyone figured out what causes this error? We are still seeing this regularly on our logs but the corresponding workflow executes normally.

Screenshot_2025-03-14_at_10.23.27_AM.png

Aalex (he/him)Found this https://developers.cloudflare.com/workflows/build/workers-api/#cross-...

Murder Chicken•3/14/25, 6:56 PM

Were you ever able to get this to work as-documented?

MMurder Chicken Because a workflow has a configuration in it's `toml` like this: ``` [[workflows...

flash716•3/14/25, 6:58 PM

Are these workflows in different Workers?

Murder Chicken•3/14/25, 6:58 PM

Yes.

Murder Chicken•3/14/25, 6:59 PM

The first worker is only invoked via scheduled handler but in workflow's last step, I need to kick off another workflow.

Murder Chicken•3/14/25, 7:02 PM

If I try and use cross-script calls like in the documentation...

WORKER A wrangler.toml

[[workflows]]
name = "workflow-a"
binding = "WORKFLOW_A"
class_name = "WorkflowA"

[[workflows]]
name = "workflow-b"
binding = "WORKFLOW_B"
class_name = "WorkflowB"
script_name = "workflow-b"

[[workflows]]
name = "workflow-a"
binding = "WORKFLOW_A"
class_name = "WorkflowA"

[[workflows]]
name = "workflow-b"
binding = "WORKFLOW_B"
class_name = "WorkflowB"
script_name = "workflow-b"

WORKER B wrangler.toml

[[workflows]]
name = "workflow-b"
binding = "WORKFLOW_B"
class_name = "WorkflowB"

[[workflows]]
name = "workflow-b"
binding = "WORKFLOW_B"
class_name = "WorkflowB"

I get the following error (like other users are reporting)...

✘ [ERROR] Worker "workflows:workflow-b"'s binding "USER_WORKFLOW" refers to a service "core:user:workflow-b", but no such service is defined.

✘ [ERROR] Worker "workflows:workflow-b"'s binding "USER_WORKFLOW" refers to a service "core:user:workflow-b", but no such service is defined.

It's worth noting that

USER_WORKFLOW

USER_WORKFLOW

is not a string that exists in my codebase, at all. NOTE: Found a reference to

USER_WORKFLOW

USER_WORKFLOW

in the workers-sdkworkers-sdk codebase: https://github.com/cloudflare/workers-sdk/blob/99f802591e65a84f509a03a4071030eb0c6c11ba/packages/miniflare/src/plugins/workflows/index.ts#L77

Murder Chicken•3/14/25, 7:04 PM

Both workflows work just fine if invoked on their own. It's when I try to configure one to be called from the other where I run into issues.

Any plans to add a way to wait for an outside event? an alternative right now would be to make a nor

Similar Threads