<@ULVA73B9P> how to change the task run name after...
# marvin-ai
i
@Marvin how to change the task run name after the task has already started
m
thought for 158.9 seconds
Yes — in Prefect 3.x you can change a task run’s name after it has started. The supported way is to update the task run via the client API:
Copy code
python
from prefect import task
from prefect.client.orchestration import get_client
from prefect.context import TaskRunContext

@task
async def my_task():
    ctx = TaskRunContext.get()
    task_run_id = ctx.task_run.id

    async with get_client() as client:
        await client.set_task_run_name(
            task_run_id=task_run_id,
            name="new-name-after-start"
        )

    return "done"
If you're in sync code:
Copy code
python
from prefect import task
from prefect.client.orchestration import get_client
from prefect.context import TaskRunContext

@task
def my_task():
    ctx = TaskRunContext.get()
    task_run_id = ctx.task_run.id

    client = get_client()
    client.set_task_run_name(
        task_run_id=task_run_id,
        name="new-name-after-start"
    )

    return "done"
Notes: - This can be done from within the running task if you grab the current task run ID from
TaskRunContext
. - It can also be done from outside the task if you already know the task run ID. - There do not appear to be state-based restrictions here — the name update is just a PATCH to the task run. If you want to set the name before execution, you can also name the task run at call time:
Copy code
python
my_task(name="initial-name")
So the short answer is: - Before start: pass
name=...
when calling the task - After start: use
client.set_task_run_name(task_run_id, ...)
If you want, I can also show the cleanest pattern for renaming based on task inputs/results so it shows nicely in the UI.
i
@Marvin Can I see parameters of the task run on the frontend of the prefect server?
m
thought for 154.4 seconds
Short answer: not in the same way as flow run parameters. In Prefect 3.x: - Flow runs have
parameters
with the actual parameter values, and those are exposed in the UI/API. - Task runs have
task_inputs
, but that is not a simple “task parameters” view with actual values.
task_inputs
stores input provenance / dependency metadata — for example whether an input came from: - a flow parameter - another task run result - a constant - a parent task dependency So for task runs, the backend/API does store input metadata, but it does not generally store/display the actual argument values as a task-parameter panel the way flow runs do. What you can expect in the frontend/server UI: - The task run UI endpoint includes
task_inputs
- But
task_inputs
is source metadata, not the concrete values passed to the task So if your question is: - “Can I see the actual values passed to a task run in the UI?”Generally no, not as first-class task parameters - “Can I see task input/dependency metadata in the API/UI data model?”Yes, via
task_inputs
Example shape of `task_inputs`:
Copy code
python
{
  "x": [{"id": "upstream-task-run-id", "input_type": "task_run_result"}],
  "y": [{"name": "my_flow_param", "input_type": "parameter"}],
}
That tells you where inputs came from, not the actual resolved values. If you need the actual task input values, common options are: - log them explicitly inside the task - inspect upstream flow parameters - inspect persisted results if result persistence is enabled Relevant distinction: -
flow_run.parameters
= actual values -
task_run.task_inputs
= references/metadata about sources If you want, I can show you how to query
task_inputs
from the API
or suggest a pattern to surface actual task arguments safely in logs/UI.
n
tl;dr you have to print them, as task run params are not in the db