I'd like to be able to treat a workflow parameter as secret similar to how workers secrets are treat

I'd like to be able to treat a workflow parameter as secret similar to how workers secrets are treated - i.e. value only retrievable within the workflow execution itself (vs. currently parameter values are output in workflow dashboard/logs etc). doesn't seem possible currently but seemed worth mentioning. use case is to pass in short-lived external service authentication credentials to a workflow run that are unique to each user in a multi-tenant system (perhaps there's a better way to implement this). thanks!

Aandyy I'd like to be able to treat a workflow parameter as secret similar to how worke...

tadhglewis•1/3/25, 12:10 PM

I'd assume these credentials are stored somewhere in your application database?

tadhglewis•1/3/25, 12:11 PM

You'd probably be better off passing in a key/ID which correlates to Secrets Manager (or a database row) which contains the creds

Ttadhglewis You'd probably be better off passing in a key/ID which correlates to Secrets Man...

andyyOP•1/3/25, 1:26 PM

thanks for the suggestion. the nice thing about passing (short-lived) secrets in as a parameter is that in a multi-tenant system it keeps simple and effective separation between tenants with a zero-trust style architecture - having the workflow worker retrieve secrets via ID requires giving the workflow access to all secrets. possible, but a greater surface area for vulnerabilities. there's also no need for the workflow to talk to other internal services if everything can be simply passed in as a param.

tadhglewis•1/3/25, 1:28 PM

Ah I realise my suggestion isn't very useful either as you can see the steps output - so if you had a step to fetch the creds, it'd be exposed.

Seems like having hidden/secret params makes sense

Ddave hmm, any ideas on why it would be stuck in `queued`?

shlomo•1/3/25, 6:41 PM

Did you ever figure out why this was the case or some help bec. Facing this same issue and have no error logs or context as to why

Kkchro3 we're seeing an issue where some workflows are getting stuck in the queue. I onl...

shlomo•1/3/25, 6:44 PM

Did you ever figure out what was causing this issue?

BBahaa Just dropping by to give my experience, workflows being marketed as a way to do ...

Chaika•1/3/25, 8:00 PM

Sleeping instances should eventually not count towards the concurrent limit: workflows
I think they might be having some issues with that tho, it is beta after all

Jadugar_Jaggu•1/3/25, 9:17 PM

Hi,

I was testing the workflow and performing some heavy tasks (really intensive ones), and occasionally encountered the error:

"The step crashed the worker (or exceeded CPU/Memory limits) during this attempt."

This error occurs in certain steps, but since most steps follow the same function with different arguments, it doesn't seem to be an issue with the function itself.

The primary challenge is that the error message doesn’t specify whether the issue was due to exceeding memory limits or CPU time limits. This lack of clarity makes it difficult to diagnose and optimize the code effectively.

It would be greatly beneficial if the error message provided precise details about the cause of the crash—whether it was due to memory usage or CPU time limits. Such information would significantly aid in troubleshooting and improving the performance of the workflow.

darren•1/4/25, 11:15 PM

Hello! I’ve been building with Workflows for the past couple of weeks. The ergonomics are really nice and I’m excited about the potential of this product.

I’ve started to notice frequent errors when attempting to make external network requests. Everything was working as expected until Dec 29. Now the majority of my requests are returning some variation of a “Connection error”.

I’m seeing this error with a few different API’s, including:

OpenAI
Resend
Cloudflare AI

I’ve also tried using Cloudflare’s AI Gateway, but didn’t notice a difference.

Example of a failed run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/5a94adfd-e01d-4f83-bf94-8729a9bbe7fc

Example of a successful run: https://dash.cloudflare.com/4f453aab7846de127d0e18aec26d1576/workers/workflows/digest-workflow/instance/1a765ea9-6e2a-4ce6-9c7c-18bf1c86d26e

Please let me know if there’s more info I can provide!

juanferreras•1/5/25, 3:23 PM

started playing with workflows yesterday – what an amazing product

D Trombett•1/5/25, 6:17 PM

https://canary.discord.com/channels/595317990191398933/1283450491837091860/1325329691460112447

Ashley•1/5/25, 10:16 PM

Is there a way that I'm not seeing in the docs to handle when a workflow fails, e.g. it would be really convenient to handle a workflow reaching max retries and ultimately failing, and being able to execute some code in the event that happens (ideally with retries

sort of like
```
finally
```
```
finally
```
in JS for try/catch).

know I can get the status with the Workers API, but that's not really useful in this case.

Scenario: an end user of an app I'm working on clicks a button in the UI that triggers a Workflow behind the scenes. The workflow could take a few seconds, or a few minutes, but no reason/guarantee the user stays on the page - and there's no need for them to. If the workflow succeeds, the last step is to update the state in D1 and then if the user navigates back to the page (or stays on it, it refreshes) it uses that state to mark the action as successful. Before that it's marked as pending, but I also want a failure state - but unless I'm missing something obvious, this seems hard to do without something else to keep track of the Workflow and check its status.

I could query for the Workflow's state or something when the page is loaded async, in the event it's pending, and then update the state so it's stored for next time but it's not really ideal - maybe I'm missing something obvious?

Original message was deleted

Ashley•1/5/25, 10:45 PM

Will that catch the very first error, and then not run the step again on a retry? Or will it… catch the error on every single re-run, assuming it errors consistently? I assume the latter? I think it’s still not going to quite work either way, as if it’s the former, I lose out on retries - assuming it’s the latter, It’d mark the workflow as failed in D1 and then it could succeed next run but it’d briefly show failed to the end user

Thank you though, it might be fine as a stop gap!

Ashley•1/5/25, 10:49 PM

oooh that'd work then, thank you - do think it'd be nice if that was in the interface for Workflows to make it a little cleaner (e.g. you can define a "on_failure" param either at a step level or a workflow level (or both) and then have it execute automatically by the framework)

Ashley•1/5/25, 10:53 PM

Yeah as you were typing I had a similar thought, as then you'd need to handle retries for the "failure step handlers" and it might get a bit confusing - perhaps just in the docs it might be good to have your example to document it for steps, and then yeah for overall workflows it'd be lovely to have a failure handler

I guess for now... could you literally wrap the entire

run

run

function in try/catch and that would effectively act as a "on failure" handler? As it'd catch any step failure after retries based on what you said

AAshley Yeah as you were typing I had a similar thought, as then you'd need to handle re...

Seekerdasbatatas•1/6/25, 11:22 AM

I guess for now... could you literally wrap the entire run function in try/catch and that would effectively act as a "on failure" handler?

yhep, that would work

Ashley•1/6/25, 11:27 AM

Awesome, thank you - really enjoying workflows so far overall

AAshley Awesome, thank you - really enjoying workflows so far overall 🤓

Seekerdasbatatas•1/6/25, 11:50 AM

@Jacob | CI has some nice abstractions for o11y: https://github.com/jahands/workers-monorepo-public/tree/main/packages/workflows-helpers/src

GitHub

workers-monorepo-public/packages/workflows-helpers/src at main · ja...

A sample of my monorepo used to deploy Cloudflare Workers - jahands/workers-monorepo-public

Akash Gupta•1/6/25, 12:01 PM

Hi Cloudflare Team,
I'm currently using QUIC.cloud nameservers for my domain and I'd like to start offloading my media content to an R2 bucket. However, I want to avoid changing my existing nameserver and DNS settings if possible.
Currently, I'm using a subdomain (r2.dev) for my R2 bucket. Is there a way to configure Cloudflare to serve media from my R2 bucket while keeping my QUIC.cloud nameservers and current DNS records intact?

AAkash Gupta Hi Cloudflare Team, I'm currently using QUIC.cloud nameservers for my domain and...

Hello, I’m Allie!•1/6/25, 12:57 PM

I believe Custom Domains Setup should walk you through how it works

Luca (steebchen)•1/6/25, 1:13 PM

Is it possible to use workflows with cf pages (nextjs specifically)?

Original message was deleted

Luca (steebchen)•1/6/25, 2:28 PM

would be super cool to have that available in pages so I don't have to depend on an external workflows service. but fair, it is still beta after all, just a suggestion

Original message was deleted

Luca (steebchen)•1/6/25, 2:40 PM

understood, thanks. I might look into Workers Assets but not a priority right now

flash716•1/6/25, 9:12 PM

If I have a long delay between step failure retries (say 60 minutes or even longer) will the workflow cycle out of active state in regard to the Concurrent Workflow Instances limit while it's waiting to retry (similar to sleep) or will it stay active the entire time it's waiting to retry?

Ddarren Hello! I’ve been building with Workflows for the past couple of weeks. The ergon...

darren•1/7/25, 2:07 PM

Is it possible that these network requests could be failing because the workflow is executing in a restricted region? I've heard of OpenAI blocking some regions, but I'd be surprised if Cloudflare's own AI product would also block.

I'm having a tough time figuring out another reason why these requests would fail so often. Maybe worth noting, but

get

get

requests are ok for the most part, the requests that are failing are

post

post

.

Here's an example of the type of request I'm talking about.

      const generatedContent = await step.do("Write content", async () => {
        const ai = new OpenAI({
          apiKey: this.env.CLOUDFLARE_AI_TOKEN,
          baseURL: `https://api.cloudflare.com/client/v4/accounts/{my account id}/ai/v1`,
        });

        const result = await ai.chat.completions.create({
          model: "@cf/meta/llama-3.1-8b-instruct",
          messages: [...example]
        })

        return result.choices[0].message.content;
      })

      const generatedContent = await step.do("Write content", async () => {
        const ai = new OpenAI({
          apiKey: this.env.CLOUDFLARE_AI_TOKEN,
          baseURL: `https://api.cloudflare.com/client/v4/accounts/{my account id}/ai/v1`,
        });

        const result = await ai.chat.completions.create({
          model: "@cf/meta/llama-3.1-8b-instruct",
          messages: [...example]
        })

        return result.choices[0].message.content;
      })

oof2win2•1/7/25, 2:42 PM

heya, is there any estimate on increasing the concurrency of workflows?

Ooof2win2 heya, is there any estimate on increasing the concurrency of workflows?

Isaac McFadyen•1/7/25, 2:48 PM

https://canary.discord.com/channels/595317990191398933/1296923707792560189/1318211982578548757 and https://canary.discord.com/channels/595317990191398933/1296923707792560189/1322620898062372865

Isaac McFadyen•1/7/25, 2:48 PM

TLDR: not really, it's planned but no ETA

oof2win2•1/7/25, 2:48 PM

make sense ty

BBahaa Any word on this? Even tried wrapping my step with a try/catch with retries set ...

Seekerdasbatatas•1/7/25, 8:05 PM

Is the error happening with new instances?

Seekerdasbatatas•1/7/25, 8:11 PM

Ah I see, can you give me your account id? I'll escalate this up

Seekerdasbatatas•1/7/25, 8:12 PM

If you prefer yes, but account ids are safe to share publicly

const generatedContent = await step.do("Write content", async () => { const ai = new OpenAI({ apiKey: this.env.CLOUDFLARE_AI_TOKEN, baseURL: `https://api.cloudflare.com/client/v4/accounts/{my account id}/ai/v1`, }); const result = await ai.chat.completions.create({ model: "@cf/meta/llama-3.1-8b-instruct", messages: [...example] }) return result.choices[0].message.content; })

I'd like to be able to treat a workflow parameter as secret similar to how workers secrets are treat

Similar Threads

Similar Threads

Similar Threads