Can you have a step within a step or does it all need to be top level?
Can you have a step within a step or does it all need to be top level?
MJust for clarification the 30sec of active CPU time is for the complete workflow and not per Step right?
MYou can nest steps (try it!) 
D+1 to using the S3 API, ideally with aws4fetch.
I personally recommend considering Backblaze B2 to use within a Worker, since that way you can have caching on the
I personally recommend considering Backblaze B2 to use within a Worker, since that way you can have caching on the
fetch
Dpfff, that's not gonna stop me from shipping it in prod.
MIs there a mechanism to throttle functions that exceed the concurrency limit or we just loose them?
FI think they just get queued? If they fail, they get also queued for retry? It should not be possible to actually fail hard or get lost unless you programmatically allow this.
Cany hard retry count/timeout limits? Doesn't appear any are documented
F
CRight, and retry limit/timeout aren't on there
DPrecisely this! When the concurrency limits are the reached, new Workflow Instances are queue, until new slots become available
FWell, if your workflow constantly fails to do something it will reach the CPU execution time limit at some point 
Cthat's a good point, 30s is a lot though
Iaccording to this message though it seems like the 30s cpu time is per step...
FYou can configure exponential backoff to limit harm -> https://developers.cloudflare.com/workflows/build/sleeping-and-retrying/#retry-steps
Cnow 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 yearsFtimeout: '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
