Sébastien12/11/2020, 3:53 PM
, will the run respect that sleep before spinning up the cluster, or does a run work differently (e.g. only runs code inside the flow's task graph)?
block only defines the flow, it doesn't run it. To run the flow, you would either call
(to run locally with Core-only) or make a call to the API `create_flow_run`(using either GraphQL or the UI).
Sébastien12/11/2020, 3:58 PM
before the flow's context manager, or if I need to update the Schedule to include an
for those seconds of sleep it would've had.
, since that'll probably produce more reliable results.
Sébastien12/11/2020, 4:03 PM
would run inside the flow, right? And I need the sleep to happen before it constructs the flow.
Sébastien12/11/2020, 4:07 PM
Sébastien12/11/2020, 4:11 PM
Sébastien12/11/2020, 4:14 PM
Sébastien12/11/2020, 4:16 PM
. Long-term it's the more robust solution, but there should be a middle option.
Sébastien12/11/2020, 4:36 PM
wouldn't work right before the Flow (does it pickle only once during registration?), so I'm not sure I can be of much help.
will only run at that point and not before execution. You might try extending a resource manager and using the sleep there? Otherwise I'd suggest using a local dask executor to avoid hitting the timeouts on your current platform.
Sébastien12/11/2020, 5:18 PM
entry to say "at least X time after the last run" (for all flows vs current flow only)? The schedule would stay the same, and the adjustment could adjust itself based on the last run.