now I have even more questions about if retries reset that or not lol
now I have even more questions about if retries reset that or not lol
DNo. You can go like,
{retries: { limit: 1000000, delay: '1 second', backoff: 'constant', }, timeout: '10 minutes'},
This refers to a step config
{retries: { limit: 1000000, delay: '1 second', backoff: 'constant', }, timeout: '10 minutes'},
This refers to a step config
CCool, no limits on the timeout part either? Could do '90 years'?
The cpu time is interesting too, Skye seemed to be saying above that it was per step? If so, how do retries work with that?
The cpu time is interesting too, Skye seemed to be saying above that it was per step? If so, how do retries work with that?
DWe never tried such a value 
But yes, could do 90 years
But yes, could do 90 years
Ftimeout: 'until apocalypse'
DNo, they don't reset. If one of a. retries reached or b. timeout reached, the step fails and the workflow will stop as errored
CGot it, thanks!
ITimeout as in the 30s CPU time limit per retry?
IOr the retry timeout in the config?
DPer retry, which is, per step. Retries are chances to run the same step, until a successful outcome
Iok ok, so if a step that takes 20s of cpu time, it will be allowed to run for 20s for 100 retries, if i allow it to, gotcha. And if i have 50 steps, doing 20s of cpu time, i can do 1000s total per workflow (irregardless of retries)
DTo clarify, the CPU time of steps that failed are counted towards your quota/billing
MIs there a way to execute a cleanup function if a workflow fails?
Ibilling i assumed so, yeah. quota i'm confused. is it 30s per step, with a total of 30s for all steps summed?
Cor 30s per step attempt
Iyeah, that i'm not clear at all about
DSorry for the confusion. Billing equals quota on my statement
Iok, gotcha
Iso, excluding billing (which is the sum of all cpu time consumed, as expected)
Iyou can have up to 255 steps, each of which can consume up to 30s of cpu time
Ieach step can be retried indefinitely, each retry resets its counter of 30s (or better, each step retry is like the previous retry never occurred, except for billing purposes, of course)
DYou can always try/catch a step and manage that yourself
Chttps://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?