workers-help
pages-help
general-help
durable-objects
workers-discussions
pages-discussions
wrangler
coding-help
kv
🦀rust-on-workers
miniflare
stream
general-discussions
functions
zaraz
âš¡instant-logs
email-routing
r2
pubsub-beta
analytics-engine
d1-database
queues
workers-for-platforms
workerd
web3
🤖turnstile
radar
web-research
logs-engine
cloudflare-go
terraform-provider-cloudflare
workers-ai
browser-rendering-api
analytics
next-on-pages
cloudflare-ai
build-caching-beta
hyperdrive
vectorize
ai-gateway
python-workers-beta
vitest-integration-beta
workers-observability
workflows-beta
Latency issues
How many Workflows do you have running?
We are aware of the some performance issue under heavy load (per account) and we are working on fixes for it...
feel like i must be doing something
feel like i must be doing something stupid but trying to run the workflows-starter and getting a 500 when trying to create a workflow:
```
[wrangler:inf] GET / 500 Internal Server Error (48ms)
[wrangler:inf] GET /favicon.ico 404 Not Found (2ms)
id null...
Workflow hono workers question
Yes, you can add as bindings. Also, you can create an endpoint to manage your workflow by reaching your instance. You can start, pause or resume your workflow via that hono endpoint.
I haven't seen this mentioned anywhere
I haven't seen this mentioned anywhere in the docs - I can't figure out if sleeping executions are counted towards the concurrency limit.
https://discord.com/channels/595317990191398933/1301574574508474399...
I'm getting a `Type instantiation is
I'm getting a
Type instantiation is excessively deep and possibly infinite. in a step. I don't think it's a very complex type being returned
What is the function passed to `step.do`
What is the function passed to
step.do supposed to return? If I return anything at all from it, it causes the workflow to throw an exception after finishing successfully, every time, and I can't figure out what I'm doing wrongSocket Mode
I was just experimenting with this myself - I was about to try opening a websocket to the Slack API in Socket Mode and try to wrap the
onmessage handler with a promise that could be awaited in the step https://api.slack.com/apis/socket-modewaitForEvent
For the moment, we do not support
waitForEvent steps or events as entrypoint (focus on the "for the moment" 😉 ). One way you could achieve the intended behaviour, would be store the humam action in a KV or D1, and periodically check for that action, sleeping between checksI’ve been testing out long-running
I’ve been testing out long-running workflows and wanted to share some observations:
- Testing persistence outside of an execution loop: my main goal was to see if workflows keep their state properly when running in a loop (storing a reference of a step result outside of a loop) with longer sleep intervals (around 30 minutes). This seemed to work - state reference was not lost even when it most definitely hibernated during those long waits.
- Switching versions mid-sleep: during the second sleep cycle, I deployed a new version of the workflow. Surprisingly, it moved the execution to the new version instead of sticking with the original one and even disregarded the current active sleep cycle. Shouldn’t it use the version it was invoked with? (source)
- Dashboard wall time: the workflow mostly sat in sleep mode, but the dashboard showed a total wall time of almost 64 minutes, which doesn’t seem right given the actual activity....
Hey, been using workflows over the
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 ...
You are only charged for CPU cycles **
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
Nested steps
Heya 👋 quick question to confirm my understanding: do nested steps behave identical to non-nested ones with regards to cache usage after failures?
Specifically, if a nested step fails, would the cached results from all parent steps be reused? Or is the caching of parent steps tied to the success of the (most) inner step(s) somehow?...
Also I notice that the step name listed
Also I notice that the step name listed in the history have an int appended to them. Im not adding that so wondering why its there / where its documented
Events
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)....
Oh also, is there a way to limit
Oh also, is there a way to limit concurrency of a specific workflow?
Let's say, downstream api is 100 req/min, I'd want to prioritize the oldest workflows and also limit concurrency. How would this look like with workflows?...
would workflows work for workers for
would workflows work for workers for platforms? Use case would be generating dispatch workers with custom workflows based on user input... Would I be able to add the workflows to the same dispatch workers and create the binding to it?
how do we test the workflow using
how do we test the workflow using
wrangler dev?
```ts
✔ script to run › dev
...Using wrangler how do I get the json
Using wrangler how do I get the json output of the workflow instance? I see theres a prod api endpoint to describe it but the wrangler command prints out a formatted list
wrangler workflows instances describe workflows-starter something...So excited! Words can’t express it. We
So excited! Words can’t express it. We need this for one of our features, and we’re building our entire platform on Cloudflare. The only thing we have outside of Cloudflare is Postgres.
Limits | Cloudflare Workflows docs
Are these limits up to date? Or they gonna increase/already increased? Talking mainly about concurrency https://developers.cloudflare.com/workflows/reference/limits/