I think they just get queued? If they fail, they get also queued for retry? It should not be possibl

I 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.

Chaika•10/25/24, 2:36 PM

any hard retry count/timeout limits? Doesn't appear any are documented

CChaika any hard retry count/timeout limits? Doesn't appear any are documented

fry69OP•10/25/24, 2:37 PM

There are some limits of course -> https://developers.cloudflare.com/workflows/reference/limits/

Ffry69 There are some limits of course -> https://developers.cloudflare.com/workflows/r...

Chaika•10/25/24, 2:37 PM

Right, and retry limit/timeout aren't on there

Ffry69 I think they just get queued? If they fail, they get also queued for retry? It s...

Diogo Ferreira•10/25/24, 2:38 PM

Precisely this! When the concurrency limits are the reached, new Workflow Instances are queue, until new slots become available

CChaika Right, and retry limit/timeout aren't on there

fry69OP•10/25/24, 2:40 PM

Well, if your workflow constantly fails to do something it will reach the CPU execution time limit at some point

Ffry69 Well, if your workflow constantly fails to do something it will reach the CPU ex...

Chaika•10/25/24, 2:41 PM

that's a good point, 30s is a lot though

Original message was deleted

itsmatteomanf•10/25/24, 2:42 PM

according to this message though it seems like the 30s cpu time is per step...

CChaika that's a good point, 30s is a lot though

fry69OP•10/25/24, 2:43 PM

You can configure exponential backoff to limit harm -> https://developers.cloudflare.com/workflows/build/sleeping-and-retrying/#retry-steps

Iitsmatteomanf according to this message though it seems like the 30s cpu time is per step...

Chaika•10/25/24, 2:44 PM

now I have even more questions about if retries reset that or not lol

CChaika any hard retry count/timeout limits? Doesn't appear any are documented

Diogo Ferreira•10/25/24, 2:49 PM

No. You can go like,
{retries: { limit: 1000000, delay: '1 second', backoff: 'constant', }, timeout: '10 minutes'},

This refers to a step config

DDiogo Ferreira No. You can go like, {retries: { limit: 1000000, delay: '1 second',...

Chaika•10/25/24, 2:50 PM

Cool, 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?

CChaika Cool, no limits on the timeout part either? Could do '90 years'? The cpu time is...

Diogo Ferreira•10/25/24, 2:52 PM

We never tried such a value

But yes, could do 90 years

fry69OP•10/25/24, 2:54 PM

timeout: 'until apocalypse'

CChaika now I have even more questions about if retries reset that or not lol

Diogo Ferreira•10/25/24, 2:54 PM

No, they don't reset. If one of a. retries reached or b. timeout reached, the step fails and the workflow will stop as errored

Chaika•10/25/24, 2:58 PM

Got it, thanks!

DDiogo Ferreira No, they don't reset. If one of a. retries reached or b. timeout reached, the st...

itsmatteomanf•10/25/24, 3:32 PM

Timeout as in the 30s CPU time limit per retry?

itsmatteomanf•10/25/24, 3:33 PM

Or the retry timeout in the config?

Iitsmatteomanf Timeout as in the 30s CPU time limit per retry?

Diogo Ferreira•10/25/24, 3:34 PM

Per retry, which is, per step. Retries are chances to run the same step, until a successful outcome

DDiogo Ferreira Per retry, which is, per step. Retries are chances to run the same step, until a...

itsmatteomanf•10/25/24, 3:35 PM

ok 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)

Iitsmatteomanf ok ok, so if a step that takes 20s of cpu time, it will be allowed to run for 20...

Diogo Ferreira•10/25/24, 3:37 PM

To clarify, the CPU time of steps that failed are counted towards your quota/billing

makrdev•10/25/24, 3:37 PM

Is there a way to execute a cleanup function if a workflow fails?

DDiogo Ferreira To clarify, the CPU time of steps that failed are counted towards your quota/bil...

itsmatteomanf•10/25/24, 3:37 PM

billing i assumed so, yeah. quota i'm confused. is it 30s per step, with a total of 30s for all steps summed?

Chaika•10/25/24, 3:38 PM

or 30s per step attempt

itsmatteomanf•10/25/24, 3:38 PM

yeah, that i'm not clear at all about

Iitsmatteomanf billing i assumed so, yeah. quota i'm confused. is it 30s per step, with a total...

Diogo Ferreira•10/25/24, 3:38 PM

Sorry for the confusion. Billing equals quota on my statement

itsmatteomanf•10/25/24, 3:38 PM

ok, gotcha

itsmatteomanf•10/25/24, 3:38 PM

so, excluding billing (which is the sum of all cpu time consumed, as expected)

itsmatteomanf•10/25/24, 3:39 PM

you can have up to 255 steps, each of which can consume up to 30s of cpu time

itsmatteomanf•10/25/24, 3:40 PM

each 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)

Mmakrdev Is there a way to execute a cleanup function if a workflow fails?

Diogo Ferreira•10/25/24, 3:40 PM

You can always try/catch a step and manage that yourself

Chaika•10/25/24, 3:40 PM

https://developers.cloudflare.com/workflows/reference/limits/ is way wrong then about cpu time

Chaika•10/25/24, 3:40 PM

Compute time per Workflow | 30 seconds of active CPU time

Chaika•10/25/24, 3:40 PM

it says it's for the entire flow

CChaika https://developers.cloudflare.com/workflows/reference/limits/ is way wrong then ...

itsmatteomanf•10/25/24, 3:41 PM

yeah, from what i read there it seemed like a workflow could use up to 30s of cpu time, for all steps combined

itsmatteomanf•10/25/24, 3:41 PM

didn't clarify the retries, but i always imagined those didn't count, otherwise it'd be impossible to use and guarantee it working correctly

CChaika https://developers.cloudflare.com/workflows/reference/limits/ is way wrong then ...

Diogo Ferreira•10/25/24, 3:51 PM

It 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

Chaika•10/25/24, 3:53 PM

yea, 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

Chaika•10/25/24, 3:53 PM

Chaika•10/25/24, 3:54 PM

I 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

CChaika I think in theory this should just work always, if retries are unlimited and get...

Diogo Ferreira•10/25/24, 4:07 PM

You should be alright!

Sam•10/25/24, 4:30 PM

Currently 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)

ajgeiss0702•10/25/24, 5:40 PM

(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

AAhmad Awais also 500 limit on workflow is too small. Workflows for platforms?

Advany•10/25/24, 6:09 PM

That would be really awesome!!!

fry69OP•10/25/24, 6:11 PM

Not yet though -> would workflows work for workers for

apolodoro•10/25/24, 6:47 PM

Can 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).

makisuo•10/25/24, 8:52 PM

I keep getting this error locally with Workflows any idea?

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.

Original message was deleted

makisuo•10/25/24, 9:26 PM

code is a bit convoluted will try to get a small reproduction

Chief•10/26/24, 12:39 AM

Do retries count as a separate invocation for billing?

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.

I think they just get queued? If they fail, they get also queued for retry? It should not be possibl

Similar Threads