This should have been fixed last week. Can you share your account ID so we can see what’s off here?
This should have been fixed last week. Can you share your account ID so we can see what’s off here?
Ce62618c17826d22a8c7630187706413b
MThis should be fixed now: we believe we fixed the root cause on this (metadata out of sync).
Cunfortunately still facing the issue. both for existing workflows and a new basic example one i created to test.
M@Diogo Ferreira is looking into this now
FIs there a way to create a workflow and wait until it’s finished ? 
what would be the most elegant way.
eg. I have a hono api. Then I wanna call a workflow and once it’s finished return the result.
Is polling via promise resolve the best ?
what would be the most elegant way.eg. I have a hono api. Then I wanna call a workflow and once it’s finished return the result.
Is polling via promise resolve the best ?
TIt doesn't seem like a good fit to me. You're trying to do asynchronous work in a synchronous flow. Why not just do your workflow logic in the hono API?
TThe entire thing with Workflows is it doesn't provide guarantees on when it will finish or how quickly. You would run into issues with connection timeouts etc if you try to keep an API connection open
TIt's hard without knowledge of what you're doing but a common standard if you need to notify a consumer once async work is done is by sending them a webhook
JAny plans on increasing the step result size limit from 1MB ?
FAwesome! Thanks 
. That makes a lot of sense.
. That makes a lot of sense.TAre there plans to make Workflows recoverable? As in, previously I was using a queue + worker and failed items would go to the dead letter queue, be manually investigated and redrived/replayed if there was a code bug.
Will it be possible to retry "dead letter" Workflows?
Will it be possible to retry "dead letter" Workflows?
MHow would you want this to work? Replay the instance (which would make tracking by ID complicated) with the same params?
I think this is tied up in how we tackle versioning, which is something we’re working on but non-trivial. Some folks want workflow instances to be immutable; others for them to reflect code updates; and a few want them to update between steps (unlikely).
I could imagine a
I think this is tied up in how we tackle versioning, which is something we’re working on but non-trivial. Some folks want workflow instances to be immutable; others for them to reflect code updates; and a few want them to update between steps (unlikely).
I could imagine a
.create({fromExisting: <id>})
Pwhat
JI've started playing with workflows, and ran into the following issue. wonder if it could be related to Workflows?
https://discordapp.com/channels/595317990191398933/1324112336121888858/1324112336121888858
https://discordapp.com/channels/595317990191398933/1324112336121888858/1324112336121888858
TSo for context, my workflow does something like
Having said that, for my use case, just creating a new instance with the same params would work. I suppose I could do this already using the Workflows API
- Creates a new workflow instance with an account id which needs creating/updating
- Fetch data from internal db and create/update data in a 3rd party via their API
Having said that, for my use case, just creating a new instance with the same params would work. I suppose I could do this already using the Workflows API
MRight. We could make that (duplication) easier, but if the previous instance’s data/state expires, it’d be more error prone.
FI disagree with this. Sometimes, for some tasks, you don't want the async nature of the workflow but the durable and retry functionality without having to implement it yourself.
FSome workflows engine already supports that, like Restate, for example.
TIMO sounds like bad practice. If you want retries, configure that in your HTTP client (Axios, ky etc).
I've never heard of Restate and it doesn't look like it's being used at scale.
I've never heard of Restate and it doesn't look like it's being used at scale.
FYou lost me at "it doesn't look like it's being used at scale", end of discussion lol
H@isaacmcfadyen @isaacmcfadyen
TAnyhow I was specifically talking about CloudFlare Workflows and how they work (asynchronously)
FAnd I was talking about durable workflows and how the only upside is not async execution
FIf that's the case, there are better-suited tools for that use case 
AI'd like to be able to treat a workflow parameter as secret similar to how workers secrets are treated - i.e. value only retrievable within the workflow execution itself (vs. currently parameter values are output in workflow dashboard/logs etc). doesn't seem possible currently but seemed worth mentioning. use case is to pass in short-lived external service authentication credentials to a workflow run that are unique to each user in a multi-tenant system (perhaps there's a better way to implement this). thanks!
TI'd assume these credentials are stored somewhere in your application database?
TYou'd probably be better off passing in a key/ID which correlates to Secrets Manager (or a database row) which contains the creds
Athanks for the suggestion. the nice thing about passing (short-lived) secrets in as a parameter is that in a multi-tenant system it keeps simple and effective separation between tenants with a zero-trust style architecture - having the workflow worker retrieve secrets via ID requires giving the workflow access to all secrets. possible, but a greater surface area for vulnerabilities. there's also no need for the workflow to talk to other internal services if everything can be simply passed in as a param.
TAh I realise my suggestion isn't very useful either as you can see the steps output - so if you had a step to fetch the creds, it'd be exposed.
Seems like having hidden/secret params makes sense
Seems like having hidden/secret params makes sense
SDid you ever figure out why this was the case or some help bec. Facing this same issue and have no error logs or context as to why
SDid you ever figure out what was causing this issue?
JHi,
I was testing the workflow and performing some heavy tasks (really intensive ones), and occasionally encountered the error:
"The step crashed the worker (or exceeded CPU/Memory limits) during this attempt."
This error occurs in certain steps, but since most steps follow the same function with different arguments, it doesn't seem to be an issue with the function itself.
The primary challenge is that the error message doesn’t specify whether the issue was due to exceeding memory limits or CPU time limits. This lack of clarity makes it difficult to diagnose and optimize the code effectively.
It would be greatly beneficial if the error message provided precise details about the cause of the crash—whether it was due to memory usage or CPU time limits. Such information would significantly aid in troubleshooting and improving the performance of the workflow.
I was testing the workflow and performing some heavy tasks (really intensive ones), and occasionally encountered the error:
"The step crashed the worker (or exceeded CPU/Memory limits) during this attempt."
This error occurs in certain steps, but since most steps follow the same function with different arguments, it doesn't seem to be an issue with the function itself.
The primary challenge is that the error message doesn’t specify whether the issue was due to exceeding memory limits or CPU time limits. This lack of clarity makes it difficult to diagnose and optimize the code effectively.
It would be greatly beneficial if the error message provided precise details about the cause of the crash—whether it was due to memory usage or CPU time limits. Such information would significantly aid in troubleshooting and improving the performance of the workflow.
DHello! I’ve been building with Workflows for the past couple of weeks. The ergonomics are really nice and I’m excited about the potential of this product.
I’ve started to notice frequent errors when attempting to make external network requests. Everything was working as expected until Dec 29. Now the majority of my requests are returning some variation of a “Connection error”.
I’m seeing this error with a few different API’s, including:
Example of a failed run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/5a94adfd-e01d-4f83-bf94-8729a9bbe7fc
Example of a successful run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/1a765ea9-6e2a-4ce6-9c7c-18bf1c86d26e
Please let me know if there’s more info I can provide!
I’ve started to notice frequent errors when attempting to make external network requests. Everything was working as expected until Dec 29. Now the majority of my requests are returning some variation of a “Connection error”.
I’m seeing this error with a few different API’s, including:
- OpenAI
- Resend
- Cloudflare AI
Example of a failed run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/5a94adfd-e01d-4f83-bf94-8729a9bbe7fc
Example of a successful run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/1a765ea9-6e2a-4ce6-9c7c-18bf1c86d26e
Please let me know if there’s more info I can provide!
Jstarted playing with workflows yesterday – what an amazing product
AIs there a way that I'm not seeing in the docs to handle when a workflow fails, e.g. it would be really convenient to handle a workflow reaching max retries and ultimately failing, and being able to execute some code in the event that happens (ideally with retries 
Scenario: an end user of an app I'm working on clicks a button in the UI that triggers a Workflow behind the scenes. The workflow could take a few seconds, or a few minutes, but no reason/guarantee the user stays on the page - and there's no need for them to. If the workflow succeeds, the last step is to update the state in D1 and then if the user navigates back to the page (or stays on it, it refreshes) it uses that state to mark the action as successful. Before that it's marked as pending, but I also want a failure state - but unless I'm missing something obvious, this seems hard to do without something else to keep track of the Workflow and check its status.
I could query for the Workflow's state or something when the page is loaded async, in the event it's pending, and then update the state so it's stored for next time but it's not really ideal - maybe I'm missing something obvious?
- sort of like
in JS for try/catch).finally
Scenario: an end user of an app I'm working on clicks a button in the UI that triggers a Workflow behind the scenes. The workflow could take a few seconds, or a few minutes, but no reason/guarantee the user stays on the page - and there's no need for them to. If the workflow succeeds, the last step is to update the state in D1 and then if the user navigates back to the page (or stays on it, it refreshes) it uses that state to mark the action as successful. Before that it's marked as pending, but I also want a failure state - but unless I'm missing something obvious, this seems hard to do without something else to keep track of the Workflow and check its status.
I could query for the Workflow's state or something when the page is loaded async, in the event it's pending, and then update the state so it's stored for next time but it's not really ideal - maybe I'm missing something obvious?
AWill that catch the very first error, and then not run the step again on a retry? Or will it… catch the error on every single re-run, assuming it errors consistently? I assume the latter? I think it’s still not going to quite work either way, as if it’s the former, I lose out on retries - assuming it’s the latter, It’d mark the workflow as failed in D1 and then it could succeed next run but it’d briefly show failed to the end user Thank you though, it might be fine as a stop gap!
Thank you though, it might be fine as a stop gap!Aoooh that'd work then, thank you - do think it'd be nice if that was in the interface for Workflows to make it a little cleaner (e.g. you can define a "on_failure" param either at a step level or a workflow level (or both) and then have it execute automatically by the framework)
AYeah as you were typing I had a similar thought, as then you'd need to handle retries for the "failure step handlers" and it might get a bit confusing - perhaps just in the docs it might be good to have your example to document it for steps, and then yeah for overall workflows it'd be lovely to have a failure handler 
I guess for now... could you literally wrap the entire
I guess for now... could you literally wrap the entire
run