https://developers.cloudflare.com/workflows/reference/limits/ is way wrong then about cpu time
https://developers.cloudflare.com/workflows/reference/limits/ is way wrong then about cpu time
CCompute time per Workflow | 30 seconds of active CPU time
Cit says it's for the entire flow
Iyeah, from what i read there it seemed like a workflow could use up to 30s of cpu time, for all steps combined
Ididn't clarify the retries, but i always imagined those didn't count, otherwise it'd be impossible to use and guarantee it working correctly
DIt may be misleading. Remember, you can also perform some work outside any step, directly in the WorkflowEntryPoint.run method. This work is still limited to 30s CPU time
Cyea, I have a silly potentially abusing workflows use case of checking for an item to propagate. In this case, a worker update. I'm abusing retries and manually throwing errors
C
CI think in theory this should just work always, if retries are unlimited and get their own cpu time, I'm not consuming any extra steps
DYou should be alright!
SCurrently I’m using queues for some ai functions that have multiple steps.
The reason I use queues as it’s a mobile app and I don’t want the user to wait too long to get an initial response that the work has started.
I write to my Postgres jobs table to say the job has started (ideally I would replace this with the workflow instance to avoid an unneeded network call)-> Processes a photo of a meal with a vision model -> queries my nutrition db -> generates macros nutrients and calories -> once succeeds or fails updated my job in my Postgres db
My frontend client subscribes via a web socket to the status of the job
Would I be better just moving this to workflows (and getting rid of the queue) as it seems to have queueing built in?
Latency is pretty important in my use case as these models take awhile and the user is expecting it to be processed under 10 seconds.
(So would be great essentially if I could reduce the need to add those additional round trips to update the job in my db by subscribing to the workflow instance instead)
The reason I use queues as it’s a mobile app and I don’t want the user to wait too long to get an initial response that the work has started.
I write to my Postgres jobs table to say the job has started (ideally I would replace this with the workflow instance to avoid an unneeded network call)-> Processes a photo of a meal with a vision model -> queries my nutrition db -> generates macros nutrients and calories -> once succeeds or fails updated my job in my Postgres db
My frontend client subscribes via a web socket to the status of the job
Would I be better just moving this to workflows (and getting rid of the queue) as it seems to have queueing built in?
Latency is pretty important in my use case as these models take awhile and the user is expecting it to be processed under 10 seconds.
(So would be great essentially if I could reduce the need to add those additional round trips to update the job in my db by subscribing to the workflow instance instead)
A(for billing) what counts as an invocation? does each step attempt count as an invocation, or is it only one invocation for the whole workflow instance?
(please ping me if you reply)
Anyone searching for this later: this was kindof partially answered here: workflows
(please ping me if you reply)
Anyone searching for this later: this was kindof partially answered here: workflows
AThat would be really awesome!!!
F
ACan a wait step have a webhook that can trigger to stop the wait and continue?
An example usecase would be an alarm system which should only be trigger if a machine is stopped for more than an hour. The workflow would begin when the machine stops and then if it turns on again before that hour an external function would call the workflow webhook and cancel the workflow (or even better cause it to take different actions than the default path).
An example usecase would be an alarm system which should only be trigger if a machine is stopped for more than an hour. The workflow would begin when the machine stops and then if it turns on again before that hour an external function would call the workflow webhook and cancel the workflow (or even better cause it to take different actions than the default path).
MI keep getting this error locally with Workflows any idea?
Mcode is a bit convoluted will try to get a small reproduction
CDo retries count as a separate invocation for billing?
DI would imagine so 
Doh invocation... hmm good question
DI hope concurrency controls are on the way! So we can say like.. only x workflows (per workflow type) can run concurrently
DFor example I think Resend limits API requests to like 40req/sec I think? So limiting the concurrency of a workflow that sends emails would be great
DWould be cool if you could set concurrency at a step level too.. not just the overall workflow
SThe api docs for instance creation has a bug in the response shape. Result is a single object and not a collection like the docs suggest
https://developers.cloudflare.com/api/operations/wor-create-new-workflow-instance
https://developers.cloudflare.com/api/operations/wor-create-new-workflow-instance
Interact with Cloudflare's products and services via the Cloudflare API
TIs it possible to have workflows defined in a pages worker?
DNo, they're just workers at the moment. This is just my opinion but they likely will stay that way with the introduction of worker assets (https://developers.cloudflare.com/workers/static-assets/)
Cloudflare Docs
Create full-stack applications deployed to Cloudflare Workers.
DWith a nested step, if a nested step fails or needs to be retried, does that mean the outer step also fails/retries?
DAlso, love the "Rules of Workflows" piece of the documentation https://developers.cloudflare.com/workflows/build/rules-of-workflows/. Definitely helps understand things a lot more. Would love to see this kind of thing on all products. Especially DO's 
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.
LWorkflows not available in the TF provider?
Cis there no way to delete workflow...?
Coh thx...
MWorkflows work fine for me in dev mode but deployed seem to never finish, eventhough the last expected step finished succesfully
MI am using EffectTS and for that reason am wrapping step.do to use it better with effect but dont really see how that could be the issue:
IYour first step for troubleshooting should probably be to see if it works without EffectTS. I don't think anyone here uses EffectTS and so the amount of help we can give when that's involved is going to be limited
Myeah will remove some and troubleshoot a bit myself Just wanted to see if someone had run into similar issues before.
Just wanted to see if someone had run into similar issues before.
Ahow do workflow updates work?
Alike if i deploy a new version of the code
DAnyone try implementing workflows into a SvelteKit app yet? 
Trying to figure out how to load a Workflow class in something other than the workflow-starter app (i.e - 
Trying to figure out how to load a Workflow class in something other than the workflow-starter app (i.e - src/index.ts file) 
BHi
BHi
Aenv.Production vs env.Preview in wrangler.tomllol
CThink they explain how it works here https://blog.cloudflare.com/workers-pricing-scale-to-zero
LYeah I remember this, but that's Workers, not Workflows
Lunless a Workflow runs on a Worker?