`Promise.all` works - we don’t change how the standard promise handling works. `sendEvent` is still
Promise.allsendEvent is still a sub-request though.
MWhat 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
.sendEvent(with unique Ids) - 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 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...FNot 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" }), that's where it was throwing the errorFand 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.
MFor many folks: yes, it can.
SIMO 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.
DHi, 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?
DBTW, 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();
await instance.terminate();
AHi, 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.
I have tried
I have tried looking at the logs of the bound worker and I can't see the log messages there either.
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.
I have tried
wrangler workflows instances describeI have tried looking at the logs of the bound worker and I can't see the log messages there either.
D@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.
Athanks! At least I don't need to waste time looking
IHello @Matt Silverlock, sorry for pinging you. Could you provide some guidance on this issue? workflowslocal dev not working
THi 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
BYou 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/
https://developers.cloudflare.com/workers/configuration/cron-triggers/
IBut the minimum cron interval would be 1 minute, no? We were hoping for something on the order of seconds
BDurable Objects with alarms that call a worker every x seconds? Is your sequential requirement per-user or for the entire work/jobs queue?
SI am seeing interesting issues with workflows. When I try to return simple object {} (empty object) as a state, workflow always logs exception but does work. Took me half a day to try and figure out what was going wrong despite it working. So far the only workaround I found is to return stringified object and from the step and then convert it back to the object and use in the remainder of the workflow. Not sure if it's a bug or expected.
ISequential requirement is per-user, not for the entire queue. Actually we'd ideally have multiple guaranteed sequential workflows per user
