Ihor Ramskyi
06/11/2026, 11:51 AMMarvin
06/11/2026, 11:51 AMMarvin
06/11/2026, 11:54 AMpython
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:
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:
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.Ihor Ramskyi
06/11/2026, 4:30 PMMarvin
06/11/2026, 4:30 PMMarvin
06/11/2026, 4:33 PMparameters 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`:
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.Nate
06/11/2026, 5:32 PM