Hello everybody. Prefect showed a very strange behavior today, which was not before. In many Flow I have type options as

start_date = Parameter("start_date", default=pendulum.now("Europe/Kiev").add(days=-1).to_date_string())
start_date = Parameter("start_date", default=(date.today() - timedelta(1)).strftime("%Y-%m-%d"))

and usually everything worked as needed, ie during the execution of the script the value of the parameter was calculated. However, I noticed that on Saturday, Sunday and Monday (today) all similar parameters were passed as 

2021-10-14

, ie as if Flow was launched on Friday. Last weekend this was not the case (as in general before)

Hi @Marko Herkaliuk, the first thing I would check is whether you use a Script-based or a Pickle based storage. Which type of storage do you use in general? By default, many storage classes pickle your flow by default, so that the default parameter value is frozen at registration time. But if you use a script-based storage, this will be evaluated at runtime resulting in a behavior that you expect.

but in Schedules config parameters is off

@Marko Herkaliuk I think the best solution is to rewrite the flow so that your default parameter value is None. Then, if parameter value is None, you are dynamically generating default start_date and end_date from a task. And if parameter is not None (e.g. custom run from UI when you do something like backfill), you use a custom parameter. Here is example code that shows what I mean:

from prefect import Flow, Parameter, task
import pendulum


@task(log_stdout=True)
def hello_world(user_input: str):
    if user_input is None:
        default_val = pendulum.now("Europe/Kiev").add(days=-1).to_date_string()
        print(f"Hello {default_val}")
    else:
        print(f"hello {user_input}")


with Flow("test-flow") as flow:
    param = Parameter("user_input", default=None)
    hw = hello_world(param)

if __name__ == '__main__':
    flow.run()
    # flow.run(parameters=dict(user_input="2021-10-17"))

@Anna Geller thanks, I know about this solution, but everything was working during few last months.

nothing I’m aware of. I could ask the team. I would still recommend making parameters static and set the dynamic default from within a task - it seems more robust 🙂

prefect:0.15.6-python3.8

We create a schedule through UI, when you do that you can set parameters, but we didn’t do that. That’s what I meant. About wrapper for the parameters - probably we make this.

Hey @Marko Herkaliuk, you are right we indeed had a change that seems to have affect it. The PR is here , the issue was that runtime parameters were not being sent to the GraphQL API. We’re looking into this.

Thnx @Kevin Kho, I am already wrapped date-based parameters, but I will waiting the news about this issue.

Hey @Marko Herkaliuk, just chatted with the team and that PR will stay because the dynamic parameter was not done by explicit design. Design-wise it’s bad that the script-based storage and pickle-based storage diverge here. This changes the previous behavior, but the current behavior is not considered a bug. Also, Orion will handle dynamic defaults natively and independently of storage so we will head in that direction.

thank you for information 🖖

Hey guys, any development here? I faced the exact same problem after upgrade from

0.15.5

to

0.15.9

@Marko Jamedzija you would need to rewrite your task so that the dynamic default Parameter value is generated from a task rather than from a Parameter. Parameter defaults were never intended to be dynamically evaluated from a flow definition, but rather they should be treated as static default values that can be optionally overridden at runtime. As Kevin said 5 answers above your message, the PR stays and is not getting reverted. If you need help in rewriting the task to use value from a task, LMK, we can help for sure.

Thanks for the answer @Anna Geller 🙂 No worries, I’m already doing the updates. I just wanted to know what’s the plan for the future, but I got it now. Thanks!

Instead of taking

schedule.next(1)[0]

, I think it may be better to retrieve this information from the context:

import prefect
prefect.context["scheduled_start_time"]

This way, you don’t rely on the schedule object that is valid only at registration time, but instead you leverage the runtime specific value of the

scheduled_start_time

.

Great, thanks! I’ll try this out 🙂