Hi, is there any Workflows downtime right now? i've been seeing a lot of 500 internal server errors
Hi, is there any Workflows downtime right now? i've been seeing a lot of 500 internal server errors today, the status page doesn't mention it.
Snot as far as I'm aware 
, could you give me your account id so I can investigate further?
, could you give me your account id so I can investigate further?
Usure here's it
adbf3651ede24f0e60bc37f80673f51f, Thanks!
BDo the workflows have a hard timeout defined? I'm running a request (lambda invoke) inside the workflow that can take up to 3 minutes to complete, but the steps fail after approximately 90 seconds.
Bbtw -- 524 error
BI haven't tried with websockt, tried with a few different request handlers from aws-sdk, node fetch and xhr, tried turning on the keep-alive and it didn't work. I'll give it a shot with websockets though
UHey, i'm noticing a lot of errors with the messages thrown by step.do. and workflows not loading on cloudflare since yesterday, this wasn't happening before
is it just me or is anyone else having the same issue?
A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset is it just me or is anyone else having the same issue?
U
SIt might be naive question but i am having hard time seeing console output. i have a workflow that makes call to AWS lambda and for some reasons lambda is returning error, to debug, i have added logs, which do not appear in workflow dashboard, and i see nothing in wrangler tail. is there any guide or recommendation on how to debug the workflow?
SI am trying to use supabase inside cloudflare workflows, and I am also using @microlabs/otel-cf-workers package. It looks like they don't work well together.
If I remove the @microlabs/otel-cf-workers, it works fine. How can I fix it?
If I remove the @microlabs/otel-cf-workers, it works fine. How can I fix it?
KJust a follow-up here, can this be documented somewhere, especially if there are plans to increase this throughput, and do you have recommendations on how to deal with this?
for example, should we have retries when creating the stub or when awaiting the create function?
for example, should we have retries when creating the stub or when awaiting the create function?
Kworkflows are fire-and-forget, so the last step of the workflow can be to a database/kv store/durable object
BIf I want to add a workflow to my nuxt app (which is hosted on worker pages), should I create a separate worker for the workflow or can it be within the same worker?
KWhen I throw NonRetryableError error , my status shows
instead of my message .
For example:
instead of my message .
For example:
KCan I read my error message somehow?
KI need this on my front-end
KI've tried to put my error message in KV, but there is like 30-60s delay on read in my worker. What would be the best way to get my custom error message on status check?
R#workers-and-pages-feature-suggestions
FWorkflows don't run on Pages. You can deploy the workflow to a Worker and call it from pages by binding - https://developers.cloudflare.com/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.
BThank you, I tried that but I didnt have access to
I've got 1 worker for my workflow and 1 for my pages app now. I'm having trouble with them talking to the same d1 instance when doing local development now tho as each folder has their own wrangler directory with d1 in the state directory
createInstance. When I ran npm run cf-typegen from my nuxt app, it made MY_WORKFLOW a Fetcher type, not Service. Maybe I did something wrong but I'm not sure?I've got 1 worker for my workflow and 1 for my pages app now. I'm having trouble with them talking to the same d1 instance when doing local development now tho as each folder has their own wrangler directory with d1 in the state directory
AI have workflow working locally and I see the binding working on remote, but when I try to trigger it via worker I am seeing TypeError: Cannot read properties of undefined (reading 'create')
below is the hono api call that triggers it
c.env.COVE_WORKFLOW_VIDEO.create({ I think it is saying that the actual workflow is not bound.below is the hono api call that triggers it
AAny plans to increase the subrequest limits, we can now run 1024 steps per workflow, however that means when we do that and every step has a subrequest, it would be over the limit. Any ideas or answers to that?
HWell, theoretically with Workflows, since errors cause a retry, once you hit the subrequest limit, the Workflow will reboot with a fresh subrequest cap, having already performed n subrequests
I^ but be careful because the step would be restarted
ISo this would only work if each subrequest was a step, or you had some method to say "worker already did first <n> requests, skip them" on restart
JGitHub
Contribute to jiangsi/vite-plugin-cloudflare-template development by creating an account on GitHub.
JWorker “workflows:workflows-starter”'s binding “USER_WORKFLOW” refers to service “core:user:” with a named entrypoint “MyWorkflow”, but “core:user:” has no such named entrypoint. MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above. at
miniflare does not support workflow, you need to use @cloudflare/vite-plugin. I wrote a demo to make the remix (react router 7) cloudflare workers project support cloudflare workflow.
see the demo https://github.com/jiangsi/vite-plugin-cloudflare-template
miniflare does not support workflow, you need to use @cloudflare/vite-plugin. I wrote a demo to make the remix (react router 7) cloudflare workers project support cloudflare workflow.
see the demo https://github.com/jiangsi/vite-plugin-cloudflare-template
GitHub
Contribute to jiangsi/vite-plugin-cloudflare-template development by creating an account on GitHub.
YAny plans to add a way to wait for an outside event? an alternative right now would be to make a normal step with a very high retry limit and a constant backoff and fail it everytime if some condition isn't met, but that seems wasteful.
Another hack to achieve this is to pause the workflow once it reaches a certain step, then resume it once some condition is met and a value is set somewhere so that the workflow can retrieve that value and continue its execution.
But some API like this would be way more efficient with a far better DX:
Another hack to achieve this is to pause the workflow once it reaches a certain step, then resume it once some condition is met and a value is set somewhere so that the workflow can retrieve that value and continue its execution.
But some API like this would be way more efficient with a far better DX:
AWhat is the correct way to bind a workflow to another Worker, so that I can trigger it from multiple workers? Is a service binding with RPC calls the only way, I thought it would be possible to bind it natively, so I can use
.create(), .status(), .terminate() from multiple workers?AAt least this sentence makes me think it should be possible:
to call into Workflows from other Workers scripts.AFound this https://developers.cloudflare.com/workflows/build/workers-api/#cross-script-calls should be what I want, however now I get this error, which others also seem to get for other setups, but my setupis worker-to-worker. I don't have
USER_WORKFLOW at all defined. Talking about local development!AAJust figured out it works when starting multiple workers with the same But now I have the issue that I have multiple workers with an entry point, and I need to write a handler locally like described here: wrangler
wrangler devwrangler dev -c apps/rest/wrangler.jsonc -c apps/workflows/wrangler.jsonc -c apps/orm/wrangler.jsonc But now I have the issue that I have multiple workers with an entry point, and I need to write a handler locally like described here: wrangler
AIt’s on the roadmap IIRC, but for now you can do what you said or use something like https://github.com/apeacock1991/workflows-wait-for-action (uses Durable Objects) to pause/resume when something happens outside your Workflow
GitHub
Contribute to apeacock1991/workflows-wait-for-action development by creating an account on GitHub.
ACan we limit concurrency of workflows when running locally with
wrangler devAny plan to increase the 1MB limit for step output and state? I would love to see at least 10MB ,maybe even 100MB
DI think for those sizes the recommendation will be to use R2 to store the state - you can have it in the same step where it's generated so if saving to R2 fails it regenerates the contents too
AWell we have files stored in R2, but we need those files in multiple steps afterwards, so following the idea that steps should be self-contained and granular, it doesn't feel right to pull files from r2 multiple times inside each step and have that part of the step too, hope my explanation makes sense
AIs there a way to specify the placement of the workflows workers? For some reason in my scenario my workers appear to be placed on the opposite coast of my db
AWould it be safe/recommended to use the following code or would that hit any limit?
AI need to wrap a workflow inside a api handler, so we can send the user response directly when the workflow finishes. I'm aware that this isn't the typical usecase for a workflow, but we don't want to implement our logic twice, once for runtime and the other for background handling. And in theory it would not be any difference if we just let the use wait for it to finish.
TFetching the status in a loop isn't exactly good. You'd be using CPU + spamming the status - not sure about exact limits though
TI wouldn't recommend it. Workflows are inherently asynchronous.
- At scale, you will eventually run into issues with the user response timing out if the workflow takes longer than expected (whether that's your code or Cloudflare delays).
- You need to handle failures from the workflow
Tbut we don't want to implement our logic twiceWhy don't you share the workflow logic by abstracting it into a function which can be called by either the Workflow or synchronous endpoint?
Trelated ^
AYeah we could try to do that!
AAnd then use a service binding i suppose?
TI was more thinking just a literal JS function that you call - assuming the workflow and endpoint are in the same repo
AThere not. We have at least 3 workers interlinked, which need the logic
TYou could also use an NPM package or workspace if you have a monorepo