What is the better way to go about this? The specific thing I am trying to do, is for a number of my flows, they need to be able to be run "per-client". So they should take in a parameter of the client's key, and load up that clients secrets so they're available for use within my other tasks that do actual work

Hi Adam - is there a reason you are choosing to use context for this? Once a run has begun, context is a read-only object. The best way to proceed here is either: • parametrize the name of your secrets, so that each client-flow pulls client-specific secrets by name • parametrize your runs via labels; this will allow you to run one agent per client, and each agent can use the

-e PREFECT__CONTEXT__SECRETS_SOMENAME=SOMEVALUE

flag to set different secret values per run, and you can label each individual run appropriately so that the right agent picks it up

@Chris White Simply wanting to have them available using the secrets api to protect them rather than parameters. Yeah, different lables / agents aren't an option. I was trying to align prefect with the context I use in my existing Talend jobs so I can migrate them

Gotcha yea it does seem the read-only nature of context isn’t well documented, I’ve made a note to make that more prominent; as you’ve described it, you aren’t really using the Secrets API which is more concerned with Cloud Secrets and Secret Tasks (which are treated in a special way, and could still be used here if you used different secret names per-client). You could achieve the same effect you’ve outlined with something like:

@task(checkpoint=False) # prevents writing the data anywhere
def load_secrets(config):
    # build dictionary of secrets as you are doing above
    return secrets_dictionary # actually return the secrets dictionary

and then accept this dictionary in your downstream tasks that need the various secrets. FYI the labels <-> agent solution is one of the supported ways you can send the same flow to different runtime environments (you can schedule a flow to run multiple times simultaneously with different labels, for example).

Gotcha, yeah the per-client different names are a no-go, suppose i'll just be passing a secret dictionary around to each task =/. Was hoping to avoid that, but that was my original fallback approach I coded up before I asked here.

One last call out — it appears you are already shipping around the

config

dictionary since it is an input to your

load_context

task, and that config object contains sensitive secret information; just wanted to raise that to your attention so that whatever task is returning the

config

object is configured in a way makes sense for your use case

Yeah that was just me testing things out, will be pulling that all out now that I know what's supported vs not. Appreciate it!

cool cool just making sure! 👍