wondering if the workflow instance limit of 100 includes workflows which are in a sleeping step?
wondering if the workflow instance limit of 100 includes workflows which are in a sleeping step?
DHmm, for some reason my workflow instance is always stuck in
queued for the statusDdo I need to start it or something?
DWhy does
.get(crypto.randomUUID()) always return an existing instance?DThat seems impossible.
Dhmm, any ideas on why it would be stuck in
queued?Dgetting pretty frustrated.
Dis this with local dev?
Dstill facing it?
Dpretty bummed, going to write off Workflows indefinitely.
WI restarted it and now got a
Network connection lost. error. pretty weird!
MWorkflows is in beta, so that’s unfortunate, but I think we’ve been clear that a few bugs are expected.
MWhat version of wrangler are you using?
DCan you please confirm you are seeing this in local dev?
DThe 100 instance limit refer to instances running. Regarding instances in a sleep step, they start the sleep in a 'running' state and will eventually change to a 'waiting' state, if the sleep is long enough. 'waiting' instances do not count towards the 100 instance limit.
Sanyone has examples for testing workflows?
FIs there any way to tell in a step that you are in a retry? If not, what's the recommended way to handle a clean-up that only runs after the last retry?
MYou would need to call the Worker over HTTP (e.g. make a fetch() call) or a Service Binding (aka "RPC") - https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/#_top
- which means only your Pages function can call the Worker and your Worker can reject any direct HTTP requests
Cloudflare Docs
Facilitate Worker-to-Worker communication.
MCloudflare Docs
A binding enables your Pages Functions to interact with resources on the Cloudflare developer platform. Use bindings to integrate your Pages Functions with Cloudflare resources like KV, Durable Objects, R2, and D1. You can set bindings for both production and preview environments.
DYes.
D3.95.0
MWhen configuring the step retry settings by setting both limit and delay to 0, the application throws an error: "e2.match is not a function". The error is only related to the delay, setting the limit to 0 works fine.
MPublished a new (draft) doc that shows some examples: https://silverlock-workflows-pages.cloudflare-docs-7ou.pages.dev/workflows/build/call-workflows-from-pages/
Cloudflare Docs
You can bind and trigger Workflows from Pages Functions by deploying a Workers project with your Workflow definition and then invoking that Worker using service bindings or a standard fetch() call.
Ssaw this blog post (https://blog.cloudflare.com/workers-vitest-integration/) which states: "Test anything exported from a Worker" - Just trying this with workflows, but running into
[vpw:inf] Starting isolated runtimes for vitest.config.mts...running the worker via
Worker "workflows:shipped"'s binding "USER_WORKFLOW" refers to service "core:user:vitest-pool-workers-runner-" with a named entrypoint "ShippedWorkflow", but "core:user:vitest-pool-workers-runner-" has no such named entrypoint.
npm run dev works as expected. Ideas?The Cloudflare Blog
Today, we’re excited to announce a new Workers Vitest integration - allowing you to write unit and integration tests via the popular testing framework, Vitest, that execute directly in our runtime, workerd!
SGitHub
Which Cloudflare product(s) does this pertain to? Miniflare, Other What version(s) of the tool(s) are you using? 0.5.32 [@cloudflare/vitest-pool-workers], 3.91.0 [wrangler] What version of Node are...
Ois there some way to temporarily fix/workaround the issue of instances getting into the stuck state, where they don't have any input and aren't triggered? is it like a thing with how many instances are created on a per-second basis?
Oseems it isn't a creation per second issue. have it in a queue, between each item there is a 1 second delay.
RThere're several messages about
My worker calls it like so
When testing locally, in about 25% of cases I get:
Is this a Miniflare issue or I'm missing something fundamental? The workflows seemingly finish correctly without errors.
An RPC stub was not disposed properly, but I still couldn't figure out the issue. I made a minimal reproducible example. My workflow has 1 step and does nothing except for logging:My worker calls it like so
When testing locally, in about 25% of cases I get:
Is this a Miniflare issue or I'm missing something fundamental? The workflows seemingly finish correctly without errors.
MMiniflare/local dev. What version of wrangler are you on?
RLatest wrangler
3.95.0MGot it. We’ll take a look!
M@Diogo Ferreira FYI
RI'm now using Workflows in production. Dozens of runs, everything works great! The ability to view each instance in the dashboard is very cool and helps a lot.
I have noticed, however, that each instance run produced an error log like this:
But each run's status is
I have noticed, however, that each instance run produced an error log like this:
But each run's status is
Successful nevertheless.M- Workflow instance IDs are unique per Workflow. The ID is the "the" identifier for finding the logs, metrics and status of an instance, even after completion. Re-using IDs would make it very hard to know if something was kicked off before.
- Why not pass the
userIdin the params, generate a composite ID e.g.${userId}-${randomHex}- and store that ID in D1? What if you had more Workflows you wanted to run for a given userId in the future? Emails? Cleanup? Different message campaigns? etc
- Error
AIs there a way to get the ID inside of the workflow, maybe inside of the
event
MNot yet but should be easy something we can add as a top-level prop on the
WorkflowEvent - @Seekerdasbatatas?
Sa question regarding pricing https://developers.cloudflare.com/workflows/reference/pricing/
A Request in this context means the initial creation of the Workflow instance, or each individual step?
Requests (invocations): the number of Workflow invocations. Subrequests made from a Workflow do not incur additional request costs.
A Request in this context means the initial creation of the Workflow instance, or each individual step?
Cloudflare Docs
Workflows pricing is identical to Workers Standard pricing and are billed on two dimensions:
DThe creation of workflow. You are allowed to run a maximum of 512 steps per workflow
MAdded additional clarity here:
SI'll check it out next week 
DOne thing that imho could be very cool too is a method to list all the running workflows
MRight now you can also use the REST API (but something we can look into on the binding)
MInteract with Cloudflare's products and services via the Cloudflare API
MDThanks, this looks perfect!
MI have a non-Workflow function that fetches, validates with Zod, and then puts data to KV.
I was thinking I could break up each step into a Workflow step, but unfortunately, the data is well above the limit:
Do I just need to put this all into 1 step to make it work?
I was thinking I could break up each step into a Workflow step, but unfortunately, the data is well above the limit:
Serialized RPC arguments or return values are limited to 1MiB, but the size of this value was: 4972045 bytes.Do I just need to put this all into 1 step to make it work?
MBut then I also feel like I lose parts of what Workflows are
