say for example if workflow.get(id) and id doesn't exist what is being returned? the documentation w
say for example if workflow.get(id) and id doesn't exist what is being returned? the documentation wasn't clear about this
MIt will throw an exception.
森any specific detail on what type of exception it would throw? since catch all is fine, but what if the exception was a different reason
MThere’s not a specific exception type yet. We should add.
MGitHub
Clarify that get throws and add an example of catching the error.
森Thank you very much!
森btw i found some minor errors on the document
森https://developers.cloudflare.com/workflows/build/workers-api/#status
this should return
this should return
Promise<InstanceStatus>Cloudflare Docs
This guide details the Workflows API within Cloudflare Workers, including methods, types, and usage examples.
森Cloudflare Docs
This guide details the Workflows API within Cloudflare Workers, including methods, types, and usage examples.
森output should return
object[]objectOpen to adding a PR? I’m about to step out as it’s the weekend
森Will do
森finally is there a way to know in the Workflow itself if it is being terminated / restarted, and allow itself to clean up some resources?
If my understanding is correct, termination only happens between each step/sleep, but there doesn't seem to be way to know if the workflow is being terminated.
If my understanding is correct, termination only happens between each step/sleep, but there doesn't seem to be way to know if the workflow is being terminated.
MNo. That also poses a challenge: how long would we allow? What if termination needs to happen faster or is due to machine failure (which would restart your workflow from the last good step elsewhere), or exceeding CPU or memory?
“Finalizers” are challenging as they set an expectation of 100% but not always the case.
“Finalizers” are challenging as they set an expectation of 100% but not always the case.
MWe might revisit this but not straightforward today.
森I see, thank you for your reply.
Alternatively, allow a workflow to "stop" (so we have a separate call
User could decide when the stop process should timeout, and call
Alternatively, allow a workflow to "stop" (so we have a separate call
workflow.get(id).stop()User could decide when the stop process should timeout, and call
terminate()If I'm not mistaken,
terminate
AHi, currently the cpu time limit on each step is 30s, does that mean the step can live up to 30s?
My step can run up to 10 minutes due to a sleep function in my dependency, but since it's not using cpu I'm not sure I can use step for this
Migrating library to workflow logic is not doable, though.
My step can run up to 10 minutes due to a sleep function in my dependency, but since it's not using cpu I'm not sure I can use step for this
Migrating library to workflow logic is not doable, though.
Sthe step can live indefinetly (sleep, wait for I/O, etc..) - those 30 seconds regard actual CPU time: think of it as 30 seconds worth of cpu cycles
Sif you are sleeping or waiting for I/O, you are not consuming cpu time
Agot it, thank you
LAny thoughts or plans about adding a websocket/SSE or similar reporting endpoint that we could subscribe to when running a Workflow? To my mind I currently need to either poll the
.status()btw,
Maximum steps per Workflow 256because I just realized this would prohibit the idea of using workflow for a long running no end-state polling process
森which workflow could be used for
森I really liked the concept of workflow; since workflow should be implemented on top of durable object (correct me if i'm wrong).
It feels like websocket implementation should be possible.
Looking through workflows documentation, it did gave me inspiration to refactor some of my internal codes so that it's a drop in replacement of workflow for Durable Objects.
(and once workflow is matured with more signals or queues then switch back)
The only down side is that the billing would be DO (so wall time and all) but it should give you all the granular steps you could ask for
(start, pause, restart, graceful stop, termination)
Let me know if you are interested!
It feels like websocket implementation should be possible.
Looking through workflows documentation, it did gave me inspiration to refactor some of my internal codes so that it's a drop in replacement of workflow for Durable Objects.
(and once workflow is matured with more signals or queues then switch back)
The only down side is that the billing would be DO (so wall time and all) but it should give you all the granular steps you could ask for
(start, pause, restart, graceful stop, termination)
Let me know if you are interested!
森Currently I think workflow lacks a few functionality, cf team let me know if there's a better place to post suggestions:
Allow a workflow to accept websocket, just like DO.
I don't think there's a good way to persist Response for SSE over
- Signal: Signal for the workflow itself to pause / resume / restart / stop; currently there's no way in a workflow to observe any signal natively, my prototype implementation involves using KV to write and read signals between each steps; still a hassle, and terminated workflow has no way to clear KV flags, so a cron job or expiring KV flags are needed.
- Long running task: It looks like the workflow has maximum steps limitation, along with the tendency to store all the results in the status, which is good for finite states; but for long, non-end state (unless interrupted) workflow, it might hit the limitation of max steps or max storage eventually since there's no way of clearing or discarding old results.
- Events: There's no way for a workflow to natively send events to other processes or back to the client, like SSE or Websocket. The workaround would be to implement would be using Queue or call upon a DO to monitor the results. (which kind of defeats the purpose of workflow).
Signals:
- First proposal: Allow the
to change; the workflow would accept the original WorkflowEvent as some of sort constructor (so it could be accessed viaWorkflowEvent<T>
etc; then the arguments in thethis.initEvent
indicates a modified arguments that the workflow can compare to; a change of value can indicate a signalrun - Second proposal: Alternatively, allow
to haveWorkflowEvent<T>
property, this property has special value that could be checked and changed unlikesignal
indicating the original value; thepayload
property can have built-in signals likesignal
to indicate a built-in option for the workflow to be informed that it should gracefully transition into a stop or cancelled state with proper clean up.shouldStop
- First proposal: Allow a previous state results to be discarded or overwritten if the same steps repeat itself (indicating a loop), this should be an opt-in behaviour and
can accept a option toWorkflowStepConfig
; this may be harder to implement then the second porposal.overrideResult - Second proposal: Allow discard of staled state results, only preserve the newest 256 results and any older results are discarded. This would transfer the responsibility to preserve old data to new results to the user end; it's easier to be implemented, and requires minimal breaking change, where first proposal can be implementated later.
Allow a workflow to accept websocket, just like DO.
I don't think there's a good way to persist Response for SSE over
step.sleep
Cisn't params something you pass to the workflow? i believe we have to define it and pass it to the WorkflowEntrypoint generics
https://developers.cloudflare.com/workflows/get-started/guide/
https://developers.cloudflare.com/workflows/get-started/guide/
DWe have a workflow that is stuck in Queued status. We can't do anything to get it out of that status. Pausing it or Terminating the instance in the dashboard does nothing (the UI just hangs). Trying to pause terminate it via the API also throws errors saying that it can moved to a different state because it is in the queed state. How do you delete or terminate a queued state? Seems like you can't get out of it.
MunknownCloudflare Docs
This guide details the Workflows API within Cloudflare Workers, including methods, types, and usage examples.
MPossibly a bug (it’s a beta!). Can you share your account ID & instance ID here?
MYou can also see more here: https://developers.cloudflare.com/workflows/build/events-and-parameters/#typescript-and-type-parameters
What you pass to
You don’t need to cast it with as - you’re passing it, and
In your Workflow you type the
What you pass to
create({params: YourType})payloadYou don’t need to cast it with as - you’re passing it, and
asIn your Workflow you type the
WorkflowEventCloudflare Docs
When a Workflow is triggered, it can receive an optional event. This event can include data that your Workflow can act on, including request details, user data fetched from your database (such as D1 or KV) or from a webhook, or messages from a Queue consumer.
Dinstance is: 079dd27c-cb60-45c9-a0f1-8bad4b169c97
MNeed both.
Dyou can probably find my account id, i don't want to add it here
HAccount IDs are safe to share, as without credentials, they cannot be used for anything
MThanks for the PR, although I don't get the benefit here - if you're passing your type as params, the type information doesn't carry through to the Workflow itself (it can't by definition: types don't work like that in JS).
Typing the
What are you actually trying to achieve here?
Typing the
paramscreateWorkflowEventWhat are you actually trying to achieve here?
MaszodI'm suggesting doing neither: typing the
paramscreateYes, we don't take things away from the free tier. It'll just have the limits we advertise: great for prototyping/hobby projects, but if you want to ship something production scale, you'll likely need to upgrade to paid.
DYeah, I don't know. i don't feel comfortable sharing Account IDs here. Anyway, the bug is that if a workflow is in a queued status it is impossible to get it out of that status. can't terminate it, pause it or do anything.
DBTW, Workflows are simply amazing. This is the greatest thing, in my opinion, to happen to Workers since I started using them a few years ago. I didn't realize it was beta, and I already moved alot of functionality to Workflows and I am just hoping not much changes when it is out of beta.
