Possibly a bug (it’s a beta!). Can you share your account ID & instance ID here?
Possibly 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}) is the payloadYou don’t need to cast it with as - you’re passing it, and
as doesn’t tell Workflows anything.In your Workflow you type the
WorkflowEvent by passing your type as the type parameter as per the docs I linked.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.
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
params property in the createWorkflowEvent because there is a serialization step in the middle.What are you actually trying to achieve here?
Mas isn't a validation either: it casts to that type. If you need to validate the params, use something like zodI'm suggesting doing neither: typing the
params property doesn't propagate type information anywhere, because the createYes, 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.
MAccount IDs are safe to share. You can't do anything with them.
d458dbe698b8eef41837f941d73bc5b3 is mine.MWithout an account ID we can't easily track it down: IDs are scoped to an account.
森Uncaught SyntaxError: The requested module 'cloudflare:workers' does not provide an export named 'WorkflowStep'uhm, did I break something...?
FI'd love to use generics when defining the workflow binding so I get the autocomplete when calling
create
AConcurrent Workflow instances (executions) is that per Workflow or per Worker Script? So if I define multiple workflows in the same worker script, do all of them have the concurrency. Would Workflow B be blocked by a lot of Workflow A instances?AAnd does anyone has thoughts about these two options. Is there any difference between them, and if so what is the difference?
森i was on wrangler 3.90.0 (i did try to update it, and delete the .wrangler file)
森i copied the type definition as a hack for now
MIt’s account wide (all of your Workflows). We’ll be bringing per-Workflow controls, and the limit on the paid plan will increase as we go.
AHey Matt, Is sleeping until event (webhook) planned for this year?
SWe've bumped up step limits to 512 per workflow: https://developers.cloudflare.com/workflows/reference/limits/
- happy thanksgiving to y'all
Cloudflare Docs
Limits that apply to authoring, deploying, and running Workflows are detailed below.
KI've seen several comments about this error response:
but i don't think anyone's responded to them. Any idea what this is about?
but i don't think anyone's responded to them. Any idea what this is about?
1I think if you need a stub after it has returned its value, you should
dup() it then dispose() of the original?
Kgot it, thanks
AI want to create a workflow which takes an input of list of APIs to be called. I want to loop over the list and call the API in a step.do, do workflows support this?
AIf I rename a workflow binding, it get's added as a new entry to the dashboard.. Is there a way to delete registered workflows? How can I get rid of them in the UI and remove them from the system completely.. otherwise we end up with a lot of stale stuff 
Swe don't a delete endpoint for workflows - it's coming :soonsoontm:
1I cant read 
AI'm getting this:
My Params type look like this:
It looks like Workflows does not support optional params, is that correct?
UNDEFINED_VALUE: Undefined values are not allowedMy Params type look like this:
It looks like Workflows does not support optional params, is that correct?
ASounds good. I have like roughly 10k instances brokenly queued. How to bulk terminate them?
Fis there a way to know within a step if it's retrying, and if so, can you get the error that made it fail?
ADid we just loose the Wall Time per Step in the Dashboard? It was very nice to see how long a step took for a specific instance
AWhat are some ideas around reducing state byte size. I'm currently facing an issue where I either reach the step count limit or subrequest limit, so the solution is to combine things, but then I'm facing the size limit. I think the state size limit should be easier to increase maybe to 10MiB?
SIn these cases I would recommend storing the result to KV/R2 and just return the key
AAnd retrieving it in the next step again?
Swhen you need it yes
1KV is usually in single milliseconds for hot reads, overall that shouldn't be an issue
AGood idea, haven’t thought about that approach. I’ll see how it will help 
AYeah I was also thinking about KV instead of R2, I think just making sure to clean-up that KV is important, but otherwise it should be totally fine. It’s a background job, so not too concerned about latency
Fany idea why i get this error when using this retry policy
{ retries: { limit: 12, delay: '2s', backoff: 'constant' } }FIf I remove the retry policy then I don't get any error