It applies prospectively, not retroactively. So if you just created the automation, it generally will not go back and catch old flow runs that were already running for more than 24 hours before the automation existed. It will apply to flow runs that enter the relevant state after the automation is in place. In practice: - A flow already running for 30 hours when you create the automation: usually no, it won’t be auto-cancelled by that new automation - A flow that starts after the automation is created and then exceeds 24 hours: yes, that’s the intended case If you want to handle the already-running ones, you’d need to cancel those separately once, then let the automation cover future runs. If helpful, I can also show you: - how this works specifically for event vs metric automations, or - a quick way to find/cancel currently long-running flow runs.

Yes — for

task_run_name

, Prefect uses Python-style format strings, so you can do more than just

{foo}

. Supported examples: -

{foo}

→ uses

str(foo)

-

{foo.a}

→ yes, attribute access works -

{foo.params[bar]}

→ yes, dict/item access works -

{items[0]}

→ list indexing works too So for your examples:

python
@task(task_run_name="{foo.a}")
def my_task(foo):
    ...

and

python
@task(task_run_name="{foo.params[bar]}")
def my_task(foo):
    ...

should work, assuming: -

foo.a

exists -

foo.params

is dict-like -

bar

is a key in that dict A couple of notes: - Use

{foo.params[bar]}

, not

{foo.params['bar']}

in the format string - You cannot do arbitrary Python expressions inside the braces - no

{foo.a.upper()}

- no

{foo.params.get('bar')}

- no

{x + 1}

If you need more complex logic, use a callable instead:

python
def custom_name(parameters):
    foo = parameters["foo"]
    return f"{foo.a}-{foo.params.get('bar', 'missing')}"

@task(task_run_name=custom_name)
def my_task(foo):
    ...

Relevant docs: - Prefect tasks docs If you want, I can give you a fully runnable example with a dataclass / Pydantic model / custom class.

Good question — in

{foo.params[bar]}

,

bar

is not treated like a Python variable lookup there. In Python format strings, the part inside

[]

is interpreted as a field/index key, not as an expression to evaluate. So:

python
"{foo.params[bar]}".format(foo=foo)

means roughly:

python
foo.params["bar"]

not:

python
foo.params[bar]

with

bar

looked up as a separate variable. So if:

python
foo.params = {"bar": "hello"}

then:

python
@task(task_run_name="{foo.params[bar]}")
def my_task(foo):
    ...

will resolve to

"hello"

. A few examples:

python
"{x[a]}".format(x={"a": 1})

→

1

python
"{x[bar]}".format(x={"bar": 2})

→

2

But this is format-string syntax, not general Python expression syntax. That’s why: -

{foo.a}

works as attribute access -

{foo.params[bar]}

works as dict key

"bar"

-

{foo.params['bar']}

does not use normal Python quoting rules the way you might expect If you want, I can show the exact Python

str.format

behavior with 3-4 tiny examples side by side.