FYI y'all, we've bumped step limits again to 1024 π π§βπ³
FYI y'all, we've bumped step limits again to 1024 
Athanks for your help! if you look at this one, the instance has been stuck in the "running" status for >24 hours
Awhen it should actually be Waiting state
Athis is a serious issue for us because it's causing us to hit the 100 concurrency limit
Awe're actually rebuilding our own task system outside of workflows because it's so broken 
SYou can try to terminate those hanging ones, to free up space - feel free to send any instance thats stuck to my dms (to not clog up this chat)
Ci love y'all 
@Seekerdasbatatas thanks for keeping updates coming our way and improving the product each day according to the user needs. you guys are the best!
@Seekerdasbatatas thanks for keeping updates coming our way and improving the product each day according to the user needs. you guys are the best!
WHowdy all, I'm trying about workflow and saw this doc to running it locally, https://developers.cloudflare.com/workflows/build/local-development/, is there a way for me to test out the workflow? I know that
npx wrangler workflowCloudflare Docs
Workflows support local development using Wrangler, the command-line interface for Workers. Wrangler runs an emulated version of Workflows compared to the one that Cloudflare runs globally.
MThe doc you linked shows the steps: https://developers.cloudflare.com/workflows/build/local-development/#start-a-local-development-session
Cloudflare Docs
Workflows support local development using Wrangler, the command-line interface for Workers. Wrangler runs an emulated version of Workflows compared to the one that Cloudflare runs globally.
FIs there a way to delete workflows on our accounts? I canβt seem to find it either in the dashboard or api
FOops! What happens if you delete the worker bound to a workflow? Can that workflow still be used by another worker?
HI'm using workflows and I really like the built-in design to retry individual steps, very much like a multi-queue solution for each step.
However, I'm also using queues to trigger N instances of the workflow as I want to space out some external calls, so I'm using delay with the queue.
But I'd very much like the workflow to receive the original batch.
This would allow for a much more robust acknowledgement and retry mechanism. If the workflow has access to the JS API of the queue batch, it will be able to control acknowledgment of the message. By retrying the queue message, it will be able to revert back executed steps by retrying the queue message and triggering a new workfow instance resetting the state.
The step sleep is not enough for that.
Currently, I need to resort to acknowledging all messages in the queue batch as soon as the workflow is triggered regarless if it's successful.
However, I'm also using queues to trigger N instances of the workflow as I want to space out some external calls, so I'm using delay with the queue.
But I'd very much like the workflow to receive the original batch.
This would allow for a much more robust acknowledgement and retry mechanism. If the workflow has access to the JS API of the queue batch, it will be able to control acknowledgment of the message. By retrying the queue message, it will be able to revert back executed steps by retrying the queue message and triggering a new workfow instance resetting the state.
The step sleep is not enough for that.
Currently, I need to resort to acknowledging all messages in the queue batch as soon as the workflow is triggered regarless if it's successful.
ADoesn't seem to work with
wrangler types --experimental-include-runtime
DAssuming that I have a workflow which at the end returns something, can I later retrieve that value using
env.WORKFLOW.get(id).status().outputAh, I guess this is part of the following limit:
Retention limit for completed Workflow state: 3 days; 30 days
AJust as an FYI, I think there's some out of date info in the docs referring to
event.paramsevent.payload
WAsking a question re the
the limits:
I am using this to get the size of the return value
however, I notice that the value returned and the actual value shown when an error is thrown can be quite different.
how can I reliably check what is the size of a return value before returning it?
(guess this is not specific to Workflows, but it's relevant in this context because a workaround I've seen is to use ReadableStream, but that wouldn't work because of the max persisted state per step limit)
Serialized RPC arguments or return values are limited to 1MiBthe limits:
- maximum persisted state per step is 1MiB
- Workers return value can only be 1MiB
I am using this to get the size of the return value
however, I notice that the value returned and the actual value shown when an error is thrown can be quite different.
how can I reliably check what is the size of a return value before returning it?
(guess this is not specific to Workflows, but it's relevant in this context because a workaround I've seen is to use ReadableStream, but that wouldn't work because of the max persisted state per step limit)
MAlways the code as it was deployed. Weβre thinking about how to enable some options here. Lots of divisive opinions.
BHey guys is it not possible to remove a deployed workflow?
EHi everyone, any luck setting up Bugsnag?
Ois it possible to increase the number of maximum outbound requests, higher than 1k? splitting the workflow into multiple executions probably is a possibility but it seems kinda weird as a limit
Yagreed ^
Yhi will the
like the cloudflare dashboard shows the steps status so its easier to track on which step is currently processing.
i return
step_namelike the cloudflare dashboard shows the steps status so its easier to track on which step is currently processing.
i return
step_name
α΄Hey team, is there an ETA on when the concurrent execution limit of 100 will be bumped? would the workflows in await steps count toward the concurrent execution limit?
we have workflows which have a total execution time of less than 10 m and want to be able to run 50K per minute and it is not a constant rate.
we have workflows which have a total execution time of less than 10 m and want to be able to run 50K per minute and it is not a constant rate.
MNot yet. Are you asking for ~833/sec or much higher? Have you tried using a Queue to manage a backlog / back off?
α΄yes 900/s or more concurrent WF, right now we are using the queue and are event based, liked the workflow model which fits our use case, we want to have multiple campaign workflows which would create multiple subscribers workflow. subscribe workflow will perform bunch steps and send out the content
MWeβre still early-ish in the beta so wonβt be 900-1000+ concurrent overnight. Recommend using a Queue here - even at scale, a Queue is going to give you the mechanisms to manage the backlog
Cany update on the infinite queued instances dilemma. currently, i'm unable to start a new instance of any workflow account wide.
MThis should have been fixed last week. Can you share your account ID so we can see whatβs off here?
Ce62618c17826d22a8c7630187706413b
MThis should be fixed now: we believe we fixed the root cause on this (metadata out of sync).
Cunfortunately still facing the issue. both for existing workflows and a new basic example one i created to test.
M@Diogo Ferreira is looking into this now
FIs there a way to create a workflow and wait until itβs finished ? 
what would be the most elegant way.
eg. I have a hono api. Then I wanna call a workflow and once itβs finished return the result.
Is polling via promise resolve the best ?
what would be the most elegant way.eg. I have a hono api. Then I wanna call a workflow and once itβs finished return the result.
Is polling via promise resolve the best ?
TIt doesn't seem like a good fit to me. You're trying to do asynchronous work in a synchronous flow. Why not just do your workflow logic in the hono API?
TThe entire thing with Workflows is it doesn't provide guarantees on when it will finish or how quickly. You would run into issues with connection timeouts etc if you try to keep an API connection open
TIt's hard without knowledge of what you're doing but a common standard if you need to notify a consumer once async work is done is by sending them a webhook
JAny plans on increasing the step result size limit from 1MB ?
FAwesome! Thanks 
. That makes a lot of sense.
. That makes a lot of sense.TAre there plans to make Workflows recoverable? As in, previously I was using a queue + worker and failed items would go to the dead letter queue, be manually investigated and redrived/replayed if there was a code bug.
Will it be possible to retry "dead letter" Workflows?
Will it be possible to retry "dead letter" Workflows?
MHow would you want this to work? Replay the instance (which would make tracking by ID complicated) with the same params?
I think this is tied up in how we tackle versioning, which is something weβre working on but non-trivial. Some folks want workflow instances to be immutable; others for them to reflect code updates; and a few want them to update between steps (unlikely).
I could imagine a
I think this is tied up in how we tackle versioning, which is something weβre working on but non-trivial. Some folks want workflow instances to be immutable; others for them to reflect code updates; and a few want them to update between steps (unlikely).
I could imagine a
.create({fromExisting: <id>})
Pwhat
JI've started playing with workflows, and ran into the following issue. wonder if it could be related to Workflows?
https://discordapp.com/channels/595317990191398933/1324112336121888858/1324112336121888858
https://discordapp.com/channels/595317990191398933/1324112336121888858/1324112336121888858
TSo for context, my workflow does something like
Having said that, for my use case, just creating a new instance with the same params would work. I suppose I could do this already using the Workflows API
- Creates a new workflow instance with an account id which needs creating/updating
- Fetch data from internal db and create/update data in a 3rd party via their API
Having said that, for my use case, just creating a new instance with the same params would work. I suppose I could do this already using the Workflows API
MRight. We could make that (duplication) easier, but if the previous instanceβs data/state expires, itβd be more error prone.
FI disagree with this. Sometimes, for some tasks, you don't want the async nature of the workflow but the durable and retry functionality without having to implement it yourself.
FSome workflows engine already supports that, like Restate, for example.
TIMO sounds like bad practice. If you want retries, configure that in your HTTP client (Axios, ky etc).
I've never heard of Restate and it doesn't look like it's being used at scale.
I've never heard of Restate and it doesn't look like it's being used at scale.
