@Marvin @Adam why aren't there also "on_started" hooks for tasks and flows? are there good work-arounds for that?

why not just call your hook at the beginning of the body of the function?

Because I'd like to call a list of functions at the start and end of each task. That's now possible with flows but not for tasks.

i think we could explore an enhancement request to add this for tasks if you want to open an issue but wrt your question > are there good work-arounds for that?

@task
def some_task():
  _run_fns(partial(fn1, **kw1), ...)

  # continue

  _run_fns(partial(fn1, **kw1), ...)

Yes, thx, but rather than adding that to each task, adding and on_running hook to @tasks would solve this perfectly.

yes! i was responding to the part asking for a workaround, feel free to open an enhancement issue

Sorry, ☕. "Unauthorized: As an Enterprise Managed User, you cannot access this content" Will file outside, I guess.

ahh. i can go ahead and file one, i think the ask is well defined

vm appreciated. Ideally, if on_cancellation and on_crashed were there for @task, there would be no recoding when changing between tasks and subflows.

there are some quirks, task runs are mostly orchestrated client side for perf reasons whereas flows are server side. we can open separate issues for other hooks, will make a ticket for on_running for now

tyvm

sorry, to be clear you require a prefect server to record the orchestration activity either way with no extra config we'll spin up a server as a subprocess and write to sqlite for you but im saying broadly speaking, throughout the lifecycle of a task run we let stuff bounce around client side to avoid the overhead of constantly talking to the API (for every state change, like flow runs and previous task runs etc) therefore, there are some differences in how and when you'd run hooks for each