Hi all 🙂 I have a question regarding the usage of

flow.serialized_hash()

for flow change detection in automated flow register processes. I found out that whenever a flow is registered with a particular task, lets say

task_A

, and then I update the values of the parameters passed to the task (imagine for instance

task_A(var='typo_string') --> task_A(var='correct_string')

), the

serialized_hash()

will remain invariant and thus the flow will not work according to the last changes because it will not bump a new version to the server. Would like to know if there is a better way to do this or I might be using the wrong approach

Hey @Carlos Gutierrez, yes those parameters are not part of the flow schema saved. You can force the re-registration or you could override them through the UI parameter settings

Thank you @Kevin Kho for your help. Do you happen to know why the task parameters are not saved to the flow schema? Is it because any task should be designed in such a way that the task call may not be modified at all?

I believe what we keep in the flow schema has to do with respecting privacy and not holding data in general. For tasks specifically, it looks like we just keep the inputs but not default values. It might catch the difference if you use the Prefect Parameter.

To put you in an example, my case scenario is as follows: I have a task defined in such a way that:

@task
def reusable_task(section: str, uncontrolled_var: str):
    execute_section(section=section, arg=uncontrolled_var)

And then in the flow I would do something like:

with case(some_parameter, True):
    reusable_task(section="one", uncontrolled_var=some_parameter)

reusable_task(section="two", uncontrolled_var=some_other_parameter)

reusable_task(section="three", uncontrolled_var=some_other_other_parameter)

My bad! I see what you’re saying now. I thought it was just a task definition default input. I’ll ask someone in the core team and get back you. It seems like this should work

Great! Thank you very much @Kevin Kho 😄