You are only charged for CPU cycles **not wall time** - about the invocations, it depends on how you
You are only charged for CPU cycles not wall time - about the invocations, it depends on how you write your workflow 😅 (your retry policy, how much time do you sleep) but providing you don't wait for too long it should be 1 invocation
17 Replies
After how much sleep time does a retry count as another invocation? Or this information not publicly available? Can you give rough guidance (or best practices) to avoid too many invocations per workflow?
Not sure if I can disclose the sleep time, but it's long enough to not worry about the invocations you get per month for free 😅
Are retries a separate invocation?
I’m wondering because if it is, then in some capacity, it encourages a dev to handle retries ourselves as much as possible instead of using the system
Based on your answer, it sounds like the answer is “sometimes”
Exactly - for interval based workflows this would be very useful. In some other cases we'd want to reuse only if workflow failed, using the same id (lets say some part of id is assembled by entity id - meaning 1:1 mapping to entity) but with updated data
You should be able to write an abstraction layer for this using available primitives, I think.
It depends on much time you need to wait between retries, the system is the same as sleeps
Are we walking in the range of, seconds, minutes, hours or days/weeks? is this possible to know?
minutes, it's long enough that if you need to wait for that time or higher it's actually good that you get another invocation ahhaha
That’s very helpful, thank you, since the main use case IMO is downstream api is overwhelmed. So a few minutes is probably most obvious use cases
Is it a few minutes from the last retry or the original invocation?
from the last unit of work (last retry then)
Hey, been using workflows over the weekend, it's pretty great! I have some feedback/questions please
The output that is displayed in the UI for each step is awesome. But is it possible to copy a non-truncated version of it? Also, would it be possible to mark some as secret so it's not available?
Where do the console logs go? It looks like they appear in whatever triggered the workflows but a little hard to tie it all together
Is there any advice for unit testing?
Is it possible to increase the size limit returned by each step?
Are there any limits to the code running as part of the workflows outside of a step?
Happy to go through any of this in more detail 😁
If I need to fetch a list of 500 items and then loop over each item and do some additional fetching to transform the data, and then run another few steps inside each loop, this can be handled in workflows correct? And in this use case would it be ok to use a dynamic key inside the workflow name argument since the items id would be deterministic if the workflow needed to retry
yes, it can be handled in a Workflow
New Sleeping and Scheduling video just dropped https://youtu.be/L6gR4Yr3UW8
Cloudflare Developers
YouTube
Schedule and Sleep For Your Apps with Durable Workflow Execution a....
Cloudflare Workflows allows you to initiate sleep as an explicit step, which can be useful when you want a Workflow to wait, schedule work ahead, or pause until an input or other external state is ready.
So.. imagine you run a social media tool that allows for liking of posts and you need to reliably handle a like: incrementing the count, loggi...
Also noticed that the instance id is not included in the response for its details endpoint. Is that expected?
https://developers.cloudflare.com/api/operations/wor-describe-workflow-instance
Cloudflare API Documentation
Interact with Cloudflare's products and services via the Cloudflare API
Maybe I missed this but can I have conditional steps?
I.e. can I have steps inside of a condition?
Yes you can!
In fact, it is not included on the response. We can return it in a future release.