I think for those sizes the recommendation will be to use R2 to store the state - you can have it in

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

A

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

A

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

A

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

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

A

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

T

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

T

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

T

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

T

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

A

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

Yeah we could try to do that!

A

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

And then use a service binding i suppose?

T

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

A

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

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

T

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

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

S

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

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

S

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

F

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

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)

C

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

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

A

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

A

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

ah yep that makes sense. Thank you !

I

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')
      }
    }
  }
}

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')
      }
    }
  }
}

C

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.

L

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.

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

M

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

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

Instance

Instance

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

L

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

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

id

id

A

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

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

A

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.

A

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

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

M

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

observability.enabled: true

observability.enabled: true.

Y

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?

N

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 */})
}

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 */})
}

M

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?

C

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

Yes.

M

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

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

M

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

Because a workflow has a configuration in it's

toml

toml

toml

toml like this:

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

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

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

workflow B

workflow B needs to have a binding in

workflow A

workflow A

workflow A

workflow A, where does that binding go? Just another

[[workflows]]

[[workflows]]

[[workflows]]

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

class_name

class_name

class_name

class_name reference to exist in

workflow A

workflow A

workflow A

workflow A's index.

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

R

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

M

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

F

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

Are these workflows in different Workers?

M

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

Yes.

M

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.

M

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"

[[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"

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

✘ [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

USER_WORKFLOW

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

USER_WORKFLOW

USER_WORKFLOW

USER_WORKFLOW

USER_WORKFLOW in the

workers-sdk

workers-sdk

workers-sdk

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

M

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.

A

ajgeiss0702•3/15/25, 12:35 AM

is an option for limiting workflow concurrency on the roadmap? I would love to move a bunch of stuff over to workflows, but I don't want to overwhelm some small external apis i call, which is what I currently use queues for

K

kchro3•3/15/25, 6:54 PM

Hey folks, we continue to see error logs for our workflow that just say "run". if I filter by request ID, I can see that the workflow successfully executed other steps, so I don't know where the "run" error log is coming from.

Kkchro3 Hey folks, we continue to see error logs for our workflow that just say "run". i...

C

Chaika•3/15/25, 7:59 PM

it's just how the workflow invocations show

C

Chaika•3/15/25, 8:00 PM

https://discord.com/channels/595317990191398933/1303411588929294358/1303488051917492318

K

kchro3•3/15/25, 8:00 PM

Are they supposed to be shown as errors?

C

Chaika•3/15/25, 8:01 PM

They're not supposed to, the workflow team as in that msg wants to fix it, but they currently all do

Rrodrigo anyone figured out what causes this error? We are still seeing this regularly on...

C

Chaika•3/15/25, 8:03 PM

same as above ^, as said in the thread "for now I'd just look at the workflows page to see how your instances are doing."

K

Khafra•3/15/25, 11:55 PM

Hi, is it possible to set the retry steps after a workflow fails? For example one of my workflow steps calls a third party api where I don't know the ratelimits. I want to fail the step if I'm ratelimited, but then retry at a specific date (the api gives us this date if we're ratelimited).

I can think of some ideas like

for (const param of params) {
  while (true) {
    const response = await step.do('<random name>', { /* options to not retry */ }, ...)

    if (response.status === 429) {
      await step.sleep('ratelimit expires', Number(response.headers.get('X-RateLimit-Reset')) * 1000)
    } else {
      break
    }
  }
}

for (const param of params) {
  while (true) {
    const response = await step.do('<random name>', { /* options to not retry */ }, ...)

    if (response.status === 429) {
      await step.sleep('ratelimit expires', Number(response.headers.get('X-RateLimit-Reset')) * 1000)
    } else {
      break
    }
  }
}

for (const param of params) {
  while (true) {
    const response = await step.do('<random name>', { /* options to not retry */ }, ...)

    if (response.status === 429) {
      await step.sleep('ratelimit expires', Number(response.headers.get('X-RateLimit-Reset')) * 1000)
    } else {
      break
    }
  }
}

for (const param of params) {
  while (true) {
    const response = await step.do('<random name>', { /* options to not retry */ }, ...)

    if (response.status === 429) {
      await step.sleep('ratelimit expires', Number(response.headers.get('X-RateLimit-Reset')) * 1000)
    } else {
      break
    }
  }
}

but I'm wondering if there's anything better?

K

Khafra•3/16/25, 12:03 AM

maybe a DurableObject is better in this case

I think for those sizes the recommendation will be to use R2 to store the state - you can have it in

Similar Threads

Similar Threads

Similar Threads