Cloudflare Developers

CD

Cloudflare Developers

Welcome to the official Cloudflare Developers server. Here you can ask for help and stay updated with the latest news

Join

any idea why i get this error when using

any idea why i get this error when using this retry policy { retries: { limit: 12, delay: '2s', backoff: 'constant' } }
✘ [ERROR] Uncaught (in promise) Error: NOT NULL constraint failed: priority_queue.target_timestamp: SQLITE_CONSTRAINT
✘ [ERROR] Uncaught (in promise) Error: NOT NULL constraint failed: priority_queue.target_timestamp: SQLITE_CONSTRAINT
...

is there a way to know within a step if

is there a way to know within a step if it's retrying, and if so, can you get the error that made it fail?

Sounds good. I have like roughly 10k

Sounds good. I have like roughly 10k instances brokenly queued. How to bulk terminate them? 🤔

Ideas for noisy-neighbors in multi-tentant systems

It’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.

And does anyone has thoughts about these

And does anyone has thoughts about these two options. Is there any difference between them, and if so what is the difference?
No description

Sure, I can share some pieces that I

Sure, I can share some pieces that I reckon is relevant. Appreciate your help. I did deploy the worker, yes. wrangler.toml ```toml [[workflows]]...

Sometimes I get this error: "A call to

Sometimes I get this error: "A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset."

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
No description

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 wrong

Socket 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-mode

waitForEvent

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 checks

I’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