Why do the docs say there is a 30 Retention limit for completed Workflow state.. but then also say i
Why do the docs say there is a 30 Retention limit for completed Workflow state.. but then also say it's stored for 7 days?
JIs it not possible to get workflow logs or even see what step a workflow is currently on through the workers API, only the http API?
Ais
wrangler typeswrangler.tomlah i see, it doesn't support per-env, but does support toplevel definition
Aalso, what happens if i reuse a workflow ID? i know i'm not supposed to but...
OIDs must be unique for a workflow instance, so it will throw an error
Jhmm, is this because being able to adjust retention for a workflow is "coming soon" so it's currently fixed at 7 days?
CHi all!
I'm intersted in setting something up with Workflows, but I noticed on this page:
https://developers.cloudflare.com/workflows/build/trigger-workflows/
That:
Is this still true? It seems the page was last updated Feb 18 2025, but Workflows has been GA for a month or so now. Can anyone confirm if restart() still throws errors?
I'm intersted in setting something up with Workflows, but I noticed on this page:
https://developers.cloudflare.com/workflows/build/trigger-workflows/
That:
Is this still true? It seems the page was last updated Feb 18 2025, but Workflows has been GA for a month or so now. Can anyone confirm if restart() still throws errors?
CAdditionally, does
restart()
Mthat's pretty painful indeed! @Matt Silverlock do you have any idea of whats going on?
DIndeed, restarting a Workflow instance is still not supported, and will throw an error when called.
COkay, good to know @Diogo Ferreira
Do you expect restart()'ing an instance count to the 100 per 10 second liimit of the Maximum Workflow instance creation rate, once it is implemented?
Do you expect restart()'ing an instance count to the 100 per 10 second liimit of the Maximum Workflow instance creation rate, once it is implemented?
DProbably not. Restarting will (should) only count towards the concurrency limits
Cexcellent. I'm sure it's already in the roadmap, but +1 to getting this implemented. It's probably the only thing keeping us from moving our pretty high volume workload over
AIn the code that is calling env.WORKFLOW.create(), is there any way to wait for that workflow to complete to continue executing that code? (assume it's from another worker). I know I can call instance.status at some point after it's complete, but not sure how I know when that is, and I need some context from the workflow's result in this other spot before continuing.
I figure that I should probably restructure all of this at some point so that isn't necessary, was just trying to see if I could avoid restructuring too much of my code
I figure that I should probably restructure all of this at some point so that isn't necessary, was just trying to see if I could avoid restructuring too much of my code
MI would love to be able see logs per step in the step details view. Trying to find the step logs using Logs tab from Workers is not the best experience.
TThere's probably ways (looping until status changes) but it isn't recommended. Workflows are entirely async and there's no guarantee how quickly they'll be completed.
Instead your Workflow should emit a webhook back to where you process "workflow complete" once it's completed.
Instead your Workflow should emit a webhook back to where you process "workflow complete" once it's completed.
Gguys, when we're calling worflows from a worker request, they're going to be queued
Gand there's no other worflow running that will catch into rate limit
Gany idea?
AHey guys I‘ve got a question regardinhg sub request Limits within workflows:
I‘m fetching Images from my database within a loop about 600 ids, but right around the 300 ids done Mark, the workflow stops failing because of the Internat subrequest limit of 1000 requests for paid plan. So I‘m wondering now would I can do different?
I‘m fetching Images from my database within a loop about 600 ids, but right around the 300 ids done Mark, the workflow stops failing because of the Internat subrequest limit of 1000 requests for paid plan. So I‘m wondering now would I can do different?
F@andifined.dev I heard the cloudflare team is working to remove the subrequests limit ?
ASounds Great but when?
AThink I have to integrate some Kind of sharding here
Pdo workflows have unlimited subrequests
Ohey there, i've previously created workflows on DB changes with CDC and i created them based on some form of unique ID within the DB that I always knew was going to be unique. previously, when i backfilled CDC (say due to an outage etc), the old workflows just didn't get created but the new ones did - which is what i wanted. now when i do that though the worker errors as it can't create the workflow. is this an intended breaking change or no?
NHi, is there a way to get the statuses of multiple workflows in a single request? We have a number of workflows that we’d like to be able to get the statuses of, without making multiple parallel calls.
Jhow would I run a workflow when another workflow fails for whatever reason?
Jis there a concept of some kind of "finally" task?
Ki think you could implement an abstract base class (which your actual workflow inherits) and then you could encapsulate the logic to capture error in this base class and add a message into a queue. then another worker would trigger and start that other workflow.
JI don't think that works for the case of retry limits being reached
Kit is interesting. i didn't know about such limitation. how about:
your current workflow would just be a proxy that adds those 600ids into a queue as 600 messages. then you could configure a worker that would trigger for those messages and create a separate workflow that only work for an individual image instead of trying to process all 600 in one workflow.
your current workflow would just be a proxy that adds those 600ids into a queue as 600 messages. then you could configure a worker that would trigger for those messages and create a separate workflow that only work for an individual image instead of trying to process all 600 in one workflow.
Ki have what i described in a simpler way to log detailed error messages on what went wrong. so, from the highest level if i am able catch an error and process it, then i guess it should be possible to trigger another workflow. now that i also realize you might not even need that queue because you could consider this part as a separate step to just trigger that other workflow.
JI'm thinking for example sending a customer an email if the order workflow terminates unsuccessful, and maybe refunding their payment. Catching errors doesn't let me know if the workflow was about to terminate / if there were still retries remaining. I could of course catch any unrecoverable errors, but that would still leave the retries exhausted case
K
i have an idea, i have been working with workflows and one thing that i keep thinking is how great it would be to have a tab called "Logs" inside workflow instance that displays console.logi believe there are two different scopes at play here. step scoped code gets retried when an error happens. but workflow scoped code does not have this. below is the abstract class i am talking about and the catch part here works only once.
`
export abstract class AbstractWorkflow<T, R> extends WorkflowEntrypoint<Env, T> {
protected abstract getName(): string;
protected abstract validateInput(input: T): void;
protected abstract runStep(event: WorkflowEvent<T>, step: WorkflowStep): Promise<R>;
async run(event: WorkflowEvent<T>, step: WorkflowStep): Promise<unknown> {
console.log({
message: `${this.getName()} started.`,
level: "info",
event,
});
try {
this.validateInput(event.payload);
const output = await this.runStep(event, step);
console.log({
message: `${this.getName()} completed.`,
level: "info",
event,
output,
});
return output;
} catch (error) {
console.log({
message: `${this.getName()} failed.`,
level: "error",
event,
error,
});
throw error;
}
}
}
ABut for my understanding that‘s the whole Point of using workflows. A Workflow has steps which get retried automatically on failure und I can define some Kind of process where each step depends on the steps before. So I don‘t unterstand why it‘s necessary to implement a workaround for functionality the product itself provides 
Already implemented some Kind of workaround on my own to get around those Limits, but currently I‘m just waiting for Container compatibility because it‘s solving so much additional Problems I‘m having with workflows right know IMHO 
Already implemented some Kind of workaround on my own to get around those Limits, but currently I‘m just waiting for Container compatibility because it‘s solving so much additional Problems I‘m having with workflows right know IMHO Ki totally agree. what appealed me in the beginning was pretty much the point i could have code that can run for weeks if necessary. so it is for sure limiting to have only x amount of requests etc.
JDo you know if reaching retry limit results in an error that can be caught? Also, if I run a "cleanup" step, and then rethrow the original error, will the workflow history correctly show the step as having failed?
JAwesome, it works exactly how I hoped it would! the workflow is marked as errored, but it also has a successful "cleanup" step after the errored step
BHello! I’m wondering if anyone else is running into a similar issue that we’re having. We’ve set up a workflow which has a
waitForEventsendEvent- The route where
is being called is deployed to a Cloudflare Worker.sendEvent - No errors are being thrown when
is called, and the types match.sendEvent - The issue seems to happen when the workflow has been idle for at least 20 minutes, if the
step has only been waiting for a few minutes I haven’t recreated the issue yet, but when thewaitForEvent
step has been waiting 20+ minutes we run into the issue the majority of the time.waitForEvent - We haven’t changed any of the default retry logic in the workflow.
JAre errors not recorded if they're in the top level of a workflow?
Jhow do I see logs from a workflow?
Kthey show up in workflow instance details page but top level errors are not retried.
Kyou see them from the observability page where you track your worker logs also.
Jthey don't seem to appear on the workflow instance details page, the instance is marked as errored, but there are no steps to attach the error to so it isn't shown
Jmy solution was to wrap everything in a top level step with no retries
Ki am able to see the top level errors' messages on that page which i thought it would work the same for you sorry about that
Joh right, I do actually see something, but it just says "The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled"
Jit doesn't give me the error's message
COn my paid workers account, it seems I can’t deploy a worker with workflows. When I try publish the worker, the worker does get deployed but wrangler throws error for the ../workflows api.
Auth error
I also get an error if I try wrangler workflows list
Auth error
I also get an error if I try wrangler workflows list
