I’m looking in the code and realizing that we store both under the same context key

scheduled_start_time

, so I believe the task value overwrites the flow value

Actually I apologize, we don’t set the

scheduled_start_time

from the task at all

So I’m still looking in to figure out why you’re seeing that behavior

(though I think we actually should set a task scheduled start time for tasks that are, in fact, scheduled!)

Ah, I think I understand. This is a limitation of how we run flows in-process. I’ll need to talk to @Chris White about the best way to solve it. Essentially: we create a new

FlowRunner

class for each scheduled event. In this case, that means creating a new

FlowRunner

for the retrying task in one minute. Because the in-process runner doesn’t have a database attached, it doesn’t know what flow run originated the retry in question, so it just sets the

scheduled_start_time

to the current time

There are a couple approaches we can take to persist the appropriate context, but I want to talk to Chris before I volunteer a solution

As a temporary workaround, one can make the first task of the flow return it's scheduled_start_time and then use it as an input for subsequent tasks, so that it's captured for possible retries.

That should work for the moment, but hopefully we can come up with a first-class solution

If all goes well, look for a PR today or tomorrow

@Mikhail Akimov this PR was merged tonight, so you can take advantage of this by installing Prefect

master

. Otherwise, it will be in the next release that we expect to cut at the end of this week.

Hi @Jeremiah! Please take a look: https://github.com/PrefectHQ/prefect/pull/1418#issuecomment-526562411

Believe this will do it — https://github.com/PrefectHQ/prefect/pull/1429