Can I get workflow instance id in workflow itself? I want workflow instance id in step of that workf
Can I get workflow instance id in workflow itself? I want workflow instance id in step of that workflow.
ZYou should be able to with the
event.instanceId
B@zegevlier Worked. Thank you!
His 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
CHey 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?
MHello, 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?
MKnown issue! Working on fixing.
MAwesome, thanks!
DIf 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.
II 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.
IAlso, 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()
Sworkflows are just JS, so you can do the latter 
IDo Workflows not support
BigIntUncaught (in promise) TypeError: Do not know how to serialize a BigInt
FDoes worklows have any special consideration for
I have seen examples using a
So before testing... Wondering if a
I'm trying to simplify some flows. Like:
waitForEventI have seen examples using a
Promise.raceSo before testing... Wondering if a
Promise.allI'm trying to simplify some flows. Like:
- if I could wait for 20 events based on
bunchOfWaitForEvnts - Trigger 20 workflows based on
bunchOfWaitForEvnts - Each workflow calls
with their ID.instance.sendEvent()
Then it occurred to me that this could also help with the sub-request limit?
BYou could push to a queue and then batch to workflows in your consumer
MPromise.allsendEventWhat 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?
MIt’s just a Worker. The “script” (Worker) can expose whatever it needs to: a fetch handler, a queue handler, a workflow, a DO, etc.
MMy own Agent project is a Fetch handler (for handling requests) -> an Agent (DO underneath) + kicks off Workflows. All one project.
MPut another way: everything is a Worker.
Bhey, 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?
FGotcha 
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:
is still a sub-request thoughsendEvent
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
- 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
(with unique Ids).sendEvent - Continue execution
MSender, yep. Any "API call" is a sub-request.
MYep. It can all be in separate files, or even further. It's just code!
FFYI, 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 invalidNot sure whether this is a bug or it is intended, if the latter, it would be good to add it to the docs
FI 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
Myou mean
step.waitForEvent("name", { type: "here" })- how long do you need it to be?
Fi mean
instance.sendEvent({ type: "here" })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?
MOK, 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)
Fi think 100 bytes would be perfect, and if possible, a more helpful error message
MOK, let me chat w/ team - have some other stuff we need to solve but we try to avoid holding back quick wins like this
BIf 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?
BI'm experiencing some cases where new workflow instances are being created and remain in the
queuedWhen 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?
SCan 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
}
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
}
MThrow a
NonRetryableErrorCloudflare Docs
This guide details the Workflows API within Cloudflare Workers, including methods, types, and usage examples.
SThank you Matt!
KWe 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?
Any idea what could be happening?
KI don't see any APIs for deactivating a workflow, too...
KI 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
AHello! 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!
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!
WHello 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?
JHey 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
I hope you will fix it, cause its breaking the application
ZOur 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
Therefore if you do the following:
If
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.doTherefore if you do the following:
If
fnd
andfna
will both rerun. They better be idempotent.fnc
will not rerun because it was pulled from the workflow cache.fnb
will still have access to a, b, and c but a and c are fresh data whereas b was pulled from cache.fnd
Mhttps://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
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.
