it shouldn't happen in a production env AFAIK, but ty for letting us know, I'll raise it with the re

it shouldn't happen in a production env AFAIK, but ty for letting us know, I'll raise it with the rest of the team :MeowHeartCloudflare: (and sorry for inconvenience)

SODaLC•11/4/25, 2:14 PM

Does a step fail silently if the returned amount is more than the 1MiB? Its the only conclusion i can reach as to why my step is constantly restarting.

1984 Ford Laser•11/5/25, 1:11 AM

Has anyone tried creating a flow where a Workflow is paused when an error occurs (after an appropriate number of retries), a user/client is notified of an issue, manual intervention occurs, then the Workflow is resumed from the same point (before the current step perhaps) to continue executing? This feels like it would be very involved to orchestrate, and I would need to call out to the REST API or another Worker to be able to pause the invocation from within

.r20•11/5/25, 6:31 PM

We are seeing an overwhelming amount of "Attempt failed due to internal workflows error" again

.r20•11/5/25, 6:34 PM

What's weird is it's saying
The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled

and the internal workflows error as well

xvvvyz•11/6/25, 5:16 AM

If I have a workflow that executes steps in parallel and one step fails while the others are still running, what happens? Do the others finish or are they terminated?

SSeekerdasbatatas it shouldn't happen in a production env AFAIK, but ty for letting us know, I'll ...

divby0•11/6/25, 8:35 AM

Something else I noticed: The success rate is much lower than 50%, maybe 20%. But its not per browser launch, its per wrangler launch (process?) meaning its sticky. If it works once, it works until the next restart, even across hot reloads. If I restart, I might have to try 5-6 times until I hit success. Maybe that helps diagnosing

stephen•11/6/25, 4:44 PM

I need architecture / design guidance on my Workflow.

I have my MAIN workflow with several steps. It's working fine as-is. In step N, it produces a file (sends it to R2). As soon as the file drops onto R2, I want another, independent workflow (Worker + DO + WF) to start. How best do I trigger my other workflow so that my MAIN workflow doesn't get bogged down by the multi-step processing of this other workflow?

Sstephen I need architecture / design guidance on my Workflow. I have my MAIN workflow w...

stephen•11/6/25, 4:50 PM

Docs AI wasn't any help.

Screenshot_2025-11-06_at_10.48.49_AM.png

Sstephen I need architecture / design guidance on my Workflow. I have my MAIN workflow w...

PhoenixSpace•11/6/25, 5:06 PM

You can trigger the start of the workflow from the main one via workers bindings, but if you want true separation of concerns, why not use a queue? You can push a message to start the next one or use https://developers.cloudflare.com/reference-architecture/diagrams/storage/event-notifications-for-storage/

Cloudflare Docs

Event notifications for storage

Use Cloudflare Workers or an external service to monitor for notifications about data changes and then handle them appropriately.

PPhoenixSpace You can trigger the start of the workflow from the main one via workers bindings...

stephen•11/6/25, 5:11 PM

Thanks! This is why I asked.

I'll look into Queues.

Sstephen I need architecture / design guidance on my Workflow. I have my MAIN workflow w...

Matt Silverlock•11/6/25, 10:06 PM

You can also just... call the other Workflow. Call it, and if it successfully starts, that's it. Your "main" Workflow instance won't be blocked.

Sstephen I need architecture / design guidance on my Workflow. I have my MAIN workflow w...

Matt Silverlock•11/6/25, 10:07 PM

await step.do("kick off next workflow", {
    return await env.WORKFLOW.create(...)
})

await step.do("kick off next workflow", {
    return await env.WORKFLOW.create(...)
})

There's nothing special here. If the other workflow fails to start, it'll fail the step — just like any other API call — and invoke your retry logic. If it starts, it'll return the instance data and the step will be successful.

confusionprevails•11/7/25, 12:07 PM

is the workflow API docs site down?
https://developers.cloudflare.com/api/resources/workflows/methods/list/

confusionprevails•11/7/25, 12:12 PM

Another question -- where do i see logs for workflows, eg any logging that workflow does, how do i see those logs?

scook•11/8/25, 6:36 PM

I had a workflow that failed in production with nothing more than

internal error

internal error

. It shows "Errored" in the dashboard. Is there any more investigation I can do to know what happened? Instance: bd1a0c85-6f10-451d-a91b-ee229909d0a6

HK•11/8/25, 7:12 PM

how can I deploy a workflow in a nextjs or tanstack start wrangler project? where do I export the workflow class. workflows needs to be exported in a

src/index.ts

src/index.ts

Levi•11/11/25, 1:50 PM

Is there a recommended way to have a conditional step in a workflow? It seems like an "if" outside of a step, causes an error even if the workflow completes successfully. I'm wanting to pull a config from the KV store, so I can toggle steps on/off without having to deploy code. Should I put the conditional inside a step?

.r20•11/13/25, 10:12 PM

For workflows when I try and copy the output for a given step it says [truncated output] at the end is there any way to get the full output

ajay | dreamlit.ai•11/13/25, 11:00 PM

Hey @avenceslau something odd happened with this workflow with the SLEEP step functionality.

1- most obvious error artificat is that there appears to be 5 "wait" steps still "RUNNING" for this workflow instance
2- this workflow was supposed to run over 7 days (with 1 day wait in between each). Yet it seems to have accelerated and run in 1 day.

I double checked and we are

await

await

ing the

step.sleep

step.sleep

and we did not touch the sleep step name. Any idea on what happened here?

(link to workflow instance: https://dash.cloudflare.com/470d4729e23e8936fd2a8f6569770873/workers/workflows/trigger-workflow/instance/f70d8594-01c1-4a4c-8722-e6ace1ea29af)

Need_Not•11/14/25, 5:18 AM

How do you delete a WF instance? I have a workflow for when a user deletes their account. If the user changes their mind I can terminate it but does that get rid of the instance? If the same user goes to delete their account again I need to make a new WF with the same ID

Need_Not•11/14/25, 5:19 AM

I currently have an errored out WF and am unable to use the same ID on a new one since I can't find how to delete the old one.

Need_Not•11/14/25, 5:29 AM

of course maybe the id is supposed to be forever unique in that case how am i supposed to easily find the instance again when needed? i could store a KV but something could go wrong there too. and I would NOT want two workflows for the same user running at the same time.

NNeed_Not of course maybe the id is supposed to be forever unique in that case how am i su...

1984 Ford Laser•11/14/25, 6:38 AM

You'd wanna associate the workflow ID with the user ID in your backend somehow

11984 Ford Laser You'd wanna associate the workflow ID with the user ID in your backend somehow

Need_Not•11/14/25, 6:40 AM

correct. But i can't just put the userId as the id since i can't make another. Since I have an updatedAt field on the user i could maybe put the userId+updatedAt but can still have problems

Need_Not•11/14/25, 6:40 AM

You can't list and filter can you?

1984 Ford Laser•11/14/25, 6:42 AM

Just make a new Workflow, then save the new ID in the user's config/storage whatever

Need_Not•11/14/25, 6:49 AM

ohh yeah since i've already put a timestamp on the user for when it's going to be deleted. pass that same timestamp in the id and params. and when executing if the timestamp doesn't match just terminate

Need_Not•11/14/25, 6:51 AM

No risk of deletion since canceling the deletion would set the timestamp to null and the sql query wont delete if it's null. But the workflow sends out emails so i didn't want multiple workflows possibly spamming someone from multiple workflows and for an account that isn't going to be deleted.

Quantum64•11/14/25, 6:59 PM

why do some of my workflow instances not record their cpu time?

woops•11/14/25, 7:03 PM

Hey guys, I'm running into a persistent issue where workers report typical wall time (200ms) but my client-side ends up taking around 5-6s and timing out. Haven't been able to reproduce consistently but run into this problem every single day basically.

Here's an example of what I've logged from one of these faulty requests:

Wall time (233ms)
Request from upstream provider (LLM Inference) - (181ms)

Client-Side

While connecting

summary | reused:0 proto:h3 dns:1ms tcp:118ms tls:117ms server:2918ms total:3154ms
-> Reused indicates if this was a previously open connection.

While receiving
->

Total Time for Server Response: 3156ms

woops•11/14/25, 7:06 PM

Is wall time source of truth for when CFW returns the request?

ByteBeast•11/17/25, 5:22 AM

Hey everyone!
I'm using sleepUntil in my workflow, but when the end time is reached, the entire workflow restarts instead of resuming from the sleep step. Because of this, the sleepUntil action never completes or fails. As a result, my code detects that the step is still pending and triggers sleepUntil again, causing it to re-execute continuously.

ByteBeast•11/17/25, 6:24 AM

I also noticed that this issue only happens when the sleep duration is long, while short sleep periods work perfectly fine.

Has anyone encountered this behavior or knows why it might be happening?

d3v1an7•11/17/25, 6:59 AM

Hey all! Does a workflow that is currently in a waitForEventwaitForEvent state count towards the concurrent instances limit? And out of interest, does a workflow in this state have any active compute for listening?

Ondreian•11/17/25, 4:04 PM

I have been messing with Workflows for a week or so for ETL and the limits feel incredibly hard to deal with, specifically the 1k sub requests. Sure I could implement some complex job splitting, but it just feels like a lot of juggling and a really rough DevEx. For example, let's say you have a JSON file with a few thousand records in it you want to import into your D1 instance you're going to hit the limits almost immediately and this isn't really a "lot of work" for production.
Am I missing something here? It seems to basically only really be a viable tool for trickle emails and other short, simple workflows.

Ondreian•11/17/25, 4:06 PM

fan-out, fan-in doesn't really seem to be supported because if you start scheduling sub-workflows you will just hit the limit then as well in your orchestrator.

OOndreian I have been messing with Workflows for a week or so for ETL and the limits feel ...

xvvvyz•11/17/25, 4:16 PM

my solution to this was to pass the work off to a container.

Xxvvvyz my solution to this was to pass the work off to a container.

Ondreian•11/17/25, 4:23 PM

When you say "the work" do you mean basically every

step.do

step.do

call or just some sort of top-level orchestration that would kick off smaller workflows? If you mean all of

step.do

step.do

calls, what value is wrapping it in a workflow even adding then since you lose all of the Workflow APIs inside of the Container where the processing is being done?

xvvvyz•11/17/25, 4:26 PM

only step in my workflow has too many sub requests.

xvvvyz•11/17/25, 4:27 PM

actually now that I think of it do container requests count towards sub requests?

Ondreian•11/17/25, 4:33 PM

I don't think the rate limiter counts them as a tree, but as direct subrequests from the Workflow

xvvvyz•11/17/25, 4:37 PM

anyway this is specifically what I do on the step that would hit the limit

await step.do("generate images", async () => {
  void containerFetch(this.env, "/pdf-to-images", {
    document_id: document.id,
    file: pdf,
    workflow_id: event.instanceId,
  });
});

if (!hasLastPageImage) {
  await step.waitForEvent("images generated", {
    timeout: "1 hour",
    type: WorkflowEventType.ImagesGenerated,
  });
}

await step.do("generate images", async () => {
  void containerFetch(this.env, "/pdf-to-images", {
    document_id: document.id,
    file: pdf,
    workflow_id: event.instanceId,
  });
});

if (!hasLastPageImage) {
  await step.waitForEvent("images generated", {
    timeout: "1 hour",
    type: WorkflowEventType.ImagesGenerated,
  });
}

xvvvyz•11/17/25, 4:38 PM

since it has to upload images one by one to r2

Ondreian•11/17/25, 4:52 PM

I guess that's a viable work around. If I am evaluating that though, it's still weirdly complex and developer hostile to require that for kind of basic "workflow" operations. I would have expected that was something you could easily handle in the Workflow declaratively. The whole point of a Workflow is to let you break down complex tasks into simple, repeatable processes, not create a lot of odd architectural dependencies. What happens if you re-deploy the container in the middle of a long workflow run? Feels like it allows some weirdly potentially, non-deterministic designs to become common place. Basically now you'll need some sort of mutex deployment for your Container to make sure you don't break any in-flight work with that, or I guess a transaction system.

xvvvyz•11/17/25, 5:00 PM

you're not wrong!

xvvvyz•11/17/25, 5:01 PM

don't think it's the best but at a certain point I need to ship something (:

Ondreian•11/17/25, 5:08 PM

Not a critique of your workaround at all, as you said, you needed to ship something. Just kind of an odd choice for Cloudflare to design Workflows in a manner that doesn't really let you get too far without pulling in a lot of complexity. I guess I will just go back to my basic Queue processor fan-out strategy, it felt weird because of the lack of observability but as you've kindly advised, I don't really seem to have any other option

Ondreian•11/17/25, 5:08 PM

i very much appreciate that you ran into the same problem and had to come up with a similar sort of workaround for it, that assures me I am not just missing some glaringly obvious thing in the docs

James•11/17/25, 8:45 PM

I find workflows not great if you can't work well within its bounds. I ended up creating my own fan-out/fan-in task mgmt system w queues and a simple workflow type tracking table. A lot more flexibility for a couple days work in building an orchestrator of my own.
For mass job creation, I had to do something similar and build out a meta-handler for managing sub requests. Once I had that working, I just left it in the background and the queue mgmt is handled. I guess it's not the ideal DX, but at the same time, I prefer local control over beta-magic.

await step.do("generate images", async () => { void containerFetch(this.env, "/pdf-to-images", { document_id: document.id, file: pdf, workflow_id: event.instanceId, }); }); if (!hasLastPageImage) { await step.waitForEvent("images generated", { timeout: "1 hour", type: WorkflowEventType.ImagesGenerated, }); }

it shouldn't happen in a production env AFAIK, but ty for letting us know, I'll raise it with the re

Similar Threads

Similar Threads

Similar Threads