Keith Devens
01/26/2022, 4:51 PMrun_id
. The existing code expects that resumes maintain the same run id (which determines working directories and so on). Is there an id in Dagster that uniquely identifies a run across resumes? I see references to a `root_run_id`…prha
01/26/2022, 5:02 PMroot_run_id
(as you have identified). If you keep retrying runs, each new run will have the last attempted run as a parent_run_id
, while keeping the original run id as the root. This run group shows up in the right side panel on the Run view, showing the run lineage.
I’m not sure if that will serve your purpose. There is not a run id that uniquely identifies the entire group, but I can get the set of runs from the run group based on the common root run id.Keith Devens
01/26/2022, 5:07 PMrun_id
from the Context and setting it in the environment for the called process. I don’t see root_run_id
documented for Contexts (https://docs.dagster.io/_apidocs/execution#contexts) but I’ll experiment and see if it’s on there.root_run_id
, but context.pipeline
does, but it’s null when starting out. So, the parent run is the immediately preceding run to this one in a chain, and all can be part of a group that’s represented by the root run id, but that’s only set if there’s been a resume?prha
01/26/2022, 5:18 PMKeith Devens
01/26/2022, 5:20 PMroot_run_id
== the original run_id
, then that should get me what I need. Experimenting.root_run_id
should always be set, and should == the run_id
if it’s the first run?prha
01/26/2022, 5:30 PMKeith Devens
01/26/2022, 5:42 PMdagster_shell
.