I just updated wrangler to latest. The code snippet I posted just returns null when running locally.
I just updated wrangler to latest. The code snippet I posted just returns null when running locally.
MWhat code snippet?
MPost the actual code - a minimal reproduction.
C
thanks for the reply. Will tomorrow. Just got in bed.SJust got it working!! Awesome!! Thanks 
CSo after further investigation, it turns out any time the dev server reloads (any code change), every workflow instance disappears. This is really annoying. Is this expected?
You can repro with the workflows starter template easily.
Just run it, go to localhost:8787, record the instanceId and note that localhost:8787?instanceId=<id> shows details of the instance, add a console.log call anywhere and save, now localhost:8787?instanceId=<id> gives
You can repro with the workflows starter template easily.
npm create cloudflare@latest workflows-starter -- --template "cloudflare/workflows-starter"Just run it, go to localhost:8787, record the instanceId and note that localhost:8787?instanceId=<id> shows details of the instance, add a console.log call anywhere and save, now localhost:8787?instanceId=<id> gives
instance.not_found error.
AHello, do you have a cron mode for workflows? Let's say; start workflow A every 1st monday of the month?
FHi! Has anyone been able to get cross-script to work locally? I've seen other people encounter this issue but not seen any solutions
It works when called from the same worker, and service bindings between the workers seem to work fine, it's only an issue with the cross-script bindings.
✘ [ERROR] Worker "workflows:s3-update-status"'s binding "USER_WORKFLOW" refers to a service "core:user:integrations", but no such service is defined.It works when called from the same worker, and service bindings between the workers seem to work fine, it's only an issue with the cross-script bindings.
VWhen workflows are queued, is it normal behavior to not show the
paramsThat's normal: dev sessions don't persist by default (otherwise we'd be told we're filling up everyone's disk + clobbering test runs/local dev). What are you trying to solve across
wrangler devShow your
wranglerI mean, I think there's a big gap between never letting things expire and expiring everything for a single character code change anywhere in the project right?
And let me be clear, this is a single
Like one option is that you could have a TTL on workflow instances that defaulted to like a day or something?
And let me be clear, this is a single
wrangler devLike one option is that you could have a TTL on workflow instances that defaulted to like a day or something?
MI can't reproduce that in the same invocation (nor should I be able to): instances persist during the running
wrangler dev
MIf you change the code, that's a new invocation (reload of all state)
COh I wouldn't call that a new invocation, I only invoked it once.
MI understand where you're coming from, but I'm also explaining why this is the case
CLike, for example, my kv data doesn't disappear on each invocation right?
MWill chat w/ the team about options to opt-in to persistency here
CWhy do instances?
MInstances aren't just state on disk (unlike KV pairs) - again, understand the frustration but not the same thing.
CI really like the products you all are putting out but it's frustrating how every product behaves differently in terms of local vs remote vs what is default and what's available. I know it's early days for workflows but just wanted to give the feedback.
CIs there a way to list recently invoked workflow instances in dev? I can use the api in prod but that doesn't work for dev.
FThese are the wrangler configs. the workflow is just a simple placeholder one for now with a console log and sleep, but it works like expected when called in the same worker. But the second i add the binding in the other worker it crashes, despite being able to connect using service bindings
MThanks - taking a look!
HWill this make only one request? If not, then there's a possibility that one of the requests might fail.
VI'm trying to list or terminate workflows (both via rest api and via dashboard) returns
HTTP 500/10001 workflows.api.error.internal_serverVNow getting 503 service unavailable (7010 service unavailable)
VOk, any workflows action, even creating workflows from inside a worker (via binding) throws errors
MOne request per Workflow. You can retry any that fail (although that should be very rare). How would you expect this to be solved?
AWooo! Congrats on the launch excited for this
FGetting similar issues when using the Vitest Pool Workers lib for testing my workflow that's triggered by a Durable Object.
FLmk if you solve this, it has me stuck :kek:
Sis
envcongrats on the launch btw!
Mthis.env - ensuring you pass your
Envtype as a parameter to your Workflow class: https://developers.cloudflare.com/workflows/build/workers-api/#workflowentrypoint
Cloudflare Docs
This guide details the Workflows API within Cloudflare Workers, including methods, types, and usage examples.
MCloudflare Docs
Send invoice when shopping cart is checked out and paid for
Sgood to know, thanks! don't think i saw this documented explicitly btw
MLet me fix!
FDo you happen to know how to get passed this issue with running tests with the Vitest Pool Workers library with Workflows that are bound to a Worker and DO? Adding it in causes a similar error to what fredviken is getting. Do I need to do any extra imports in the
Snippet of my wrangler.jsonc below
vitest.config file as I have the workflow in a separate folder? The durable object class gets resolved without issue, but not the workflow.Snippet of my wrangler.jsonc below
SAre there guarantees that in flight workflow requests are allowed to finish when a new worker version is deployed?
We're ready to migrate off Durable Objects in favor of Workflows because DOs don't have this guarantee; just wanted to make sure that Workflows actually do have this property
We're ready to migrate off Durable Objects in favor of Workflows because DOs don't have this guarantee; just wanted to make sure that Workflows actually do have this property
DwaitForEvent seems really powerful, but I can't figure out how it works exactly. To trigger the event, you need to know its instanceId, await env.MY_WORKFLOW.get(instanceId)m , but how will the external service know the instanceId that is determined by the workflow internally? Your example with Stripe here: https://developers.cloudflare.com/workflows/build/events-and-parameters/#send-events-to-running-workflows is interesting, but how would Stripe know what the instance id is to trigger?
Cloudflare 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.
SCan multiple workers bind to workflows sharing the same name? For preview deploys, we currently spin up a new worker, but it shares a wrangler.toml as our production deploy, so we would have multiple workers with workflows of the same name.
This UI seems to imply that a given workflow can only have a single bound worker?
EDIT: seems like it can't. templating in our wrangler.toml seems to fix the issue...
This UI seems to imply that a given workflow can only have a single bound worker?
EDIT: seems like it can't. templating in our wrangler.toml seems to fix the issue...
IAre there any plans to lift or increase the current limit of 1,000 external requests per workflow instance? Right now, I'm having to split my workflows just to work around this restriction.
SBug report: workflows are not created in cloudflare when using gradual deploys, at least when created for the first time
MIn most cases you likely want a Worker to do the routing from webhook -> the correct instance, but if (for example) you can attach metadata to the Stripe payment event or subscription request, you can include the instance ID.
MYes, but will take a bit of time (weeks, not days).
Anow that workflows are GA/production ready, how can i delete a workflow?
DComing very soon
MWhat version of
wrangler
BIs there any sample to create workflow using api, as I am trying to make dynamic workflow where user can select how workflow will processed so does anyone have code sample or CURL or anything which can help me out?
DYeah, but the Stripe webhook that trigger the waitForEvent for a particular workflow instance will by definition fire after the workflow has already started. There is no way to put the instance id into Stripe metadata, because there is no way Stripe will have this information. You can't update stripe metadata before something you don't know will happen will happen. This is the case for nearly every single instance where you would use waitFor. The thing that will trigger the waitFor will fire AFTER the workflow starts or what are you waiting for? So there is no way the external event will ever know what the instance is. Reallly the only way I can see that this can possibly work is that both the Workflow and external event that will eventually trigger the waitForEvent both use a predetermined uniqueID that is considered unique across all workflows. In that way the Workflow instance Id would be created with that uniqueId. But this is quite challenging to get right. In the case of orders, I guess you will have a unique order ID that can possibly be shared by Stripe and the Workflow, but this would have to be created by a 3rd party system, so that Stripe and the Worfklow can both know it.
