Thank you, I tried that but I didnt have access to `createInstance`. When I ran `npm run cf-typegen`

A

I have workflow working locally and I see the binding working on remote, but when I try to trigger it via worker I am seeing TypeError: Cannot read properties of undefined (reading 'create')

c.env.COVE_WORKFLOW_VIDEO.create({

c.env.COVE_WORKFLOW_VIDEO.create({

c.env.COVE_WORKFLOW_VIDEO.create({

c.env.COVE_WORKFLOW_VIDEO.create({ I think it is saying that the actual workflow is not bound.

below is the hono api call that triggers it

.get(
        "/workflow",
        validator(
            "query",
            z.object({
                videoId: z.string().min(1),
                instanceId: z.string().optional(),
            }),
        ),
        describeRoute({
            tags: ["Video"],
        }),
        async (c) => {
            const organization = c.get("organization");
            const { instanceId, videoId } = c.req.valid("query");

            const video = await db(c.env.COVE).video.findUnique({
                where: { id: videoId, organizationId: organization?.id },
            });

            if (!video) {
                return c.json({ error: "Video not found" }, 404);
            }

            if (instanceId) {
                const instance =
                    await c.env.COVE_WORKFLOW_VIDEO.get(instanceId);
                return c.json({
                    status: await instance.status(),
                });
            }

            // Spawn a new instance and return the ID and status
            const instance = await c.env.COVE_WORKFLOW_VIDEO.create({
                params: {
                    key: video.key,
                },
            });
            return c.json({
                id: instance.id,
                details: await instance.status(),
            });
        },
    )

.get(
        "/workflow",
        validator(
            "query",
            z.object({
                videoId: z.string().min(1),
                instanceId: z.string().optional(),
            }),
        ),
        describeRoute({
            tags: ["Video"],
        }),
        async (c) => {
            const organization = c.get("organization");
            const { instanceId, videoId } = c.req.valid("query");

            const video = await db(c.env.COVE).video.findUnique({
                where: { id: videoId, organizationId: organization?.id },
            });

            if (!video) {
                return c.json({ error: "Video not found" }, 404);
            }

            if (instanceId) {
                const instance =
                    await c.env.COVE_WORKFLOW_VIDEO.get(instanceId);
                return c.json({
                    status: await instance.status(),
                });
            }

            // Spawn a new instance and return the ID and status
            const instance = await c.env.COVE_WORKFLOW_VIDEO.create({
                params: {
                    key: video.key,
                },
            });
            return c.json({
                id: instance.id,
                details: await instance.status(),
            });
        },
    )

.get(
        "/workflow",
        validator(
            "query",
            z.object({
                videoId: z.string().min(1),
                instanceId: z.string().optional(),
            }),
        ),
        describeRoute({
            tags: ["Video"],
        }),
        async (c) => {
            const organization = c.get("organization");
            const { instanceId, videoId } = c.req.valid("query");

            const video = await db(c.env.COVE).video.findUnique({
                where: { id: videoId, organizationId: organization?.id },
            });

            if (!video) {
                return c.json({ error: "Video not found" }, 404);
            }

            if (instanceId) {
                const instance =
                    await c.env.COVE_WORKFLOW_VIDEO.get(instanceId);
                return c.json({
                    status: await instance.status(),
                });
            }

            // Spawn a new instance and return the ID and status
            const instance = await c.env.COVE_WORKFLOW_VIDEO.create({
                params: {
                    key: video.key,
                },
            });
            return c.json({
                id: instance.id,
                details: await instance.status(),
            });
        },
    )

.get(
        "/workflow",
        validator(
            "query",
            z.object({
                videoId: z.string().min(1),
                instanceId: z.string().optional(),
            }),
        ),
        describeRoute({
            tags: ["Video"],
        }),
        async (c) => {
            const organization = c.get("organization");
            const { instanceId, videoId } = c.req.valid("query");

            const video = await db(c.env.COVE).video.findUnique({
                where: { id: videoId, organizationId: organization?.id },
            });

            if (!video) {
                return c.json({ error: "Video not found" }, 404);
            }

            if (instanceId) {
                const instance =
                    await c.env.COVE_WORKFLOW_VIDEO.get(instanceId);
                return c.json({
                    status: await instance.status(),
                });
            }

            // Spawn a new instance and return the ID and status
            const instance = await c.env.COVE_WORKFLOW_VIDEO.create({
                params: {
                    key: video.key,
                },
            });
            return c.json({
                id: instance.id,
                details: await instance.status(),
            });
        },
    )

A

alex (he/him)•3/7/25, 6:06 AM

Any plans to increase the subrequest limits, we can now run 1024 steps per workflow, however that means when we do that and every step has a subrequest, it would be over the limit. Any ideas or answers to that?

Aalex (he/him)Any plans to increase the subrequest limits, we can now run 1024 steps per workf...

H

Hard@Work•3/7/25, 5:18 PM

Well, theoretically with Workflows, since errors cause a retry, once you hit the subrequest limit, the Workflow will reboot with a fresh subrequest cap, having already performed n subrequests

HHard@Work Well, theoretically with Workflows, since errors cause a retry, once you hit the...

I

Isaac McFadyen•3/7/25, 6:37 PM

^ but be careful because the step would be restarted

I

Isaac McFadyen•3/7/25, 6:37 PM

So this would only work if each subrequest was a step, or you had some method to say "worker already did first <n> requests, skip them" on restart

DDom Hey! I'm trying to use Workflows within an existing Workers project. The project...

J

jasonj•3/8/25, 1:51 AM

try to use https://github.com/jiangsi/vite-plugin-cloudflare-template

GitHub

GitHub - jiangsi/vite-plugin-cloudflare-template

Contribute to jiangsi/vite-plugin-cloudflare-template development by creating an account on GitHub.

J

jasonj•3/8/25, 2:03 AM

Worker “workflows:workflows-starter”'s binding “USER_WORKFLOW” refers to service “core:user:” with a named entrypoint “MyWorkflow”, but “core:user:” has no such named entrypoint. MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above. at
miniflare does not support workflow, you need to use @cloudflare/vite-plugin. I wrote a demo to make the remix (react router 7) cloudflare workers project support cloudflare workflow.
see the demo https://github.com/jiangsi/vite-plugin-cloudflare-template

GitHub

GitHub - jiangsi/vite-plugin-cloudflare-template

Contribute to jiangsi/vite-plugin-cloudflare-template development by creating an account on GitHub.

Y

Yassine•3/8/25, 4:17 AM

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

A

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

.create()

.create(),

.status()

.status()

.status()

.status(),

.terminate()

.terminate()

from multiple workers?

A

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.

to call into Workflows from other Workers scripts.

to call into Workflows from other Workers scripts.

A

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.

A

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

A

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

A

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.

A

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

Can we limit concurrency of workflows when running locally with

wrangler dev

wrangler dev

?

A

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

D

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

A

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

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

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

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

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

, 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

.

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?

Thank you, I tried that but I didnt have access to `createInstance`. When I ran `npm run cf-typegen`

Similar Threads