#1848 [Core feature] [flytekit] FlyteRemote workflow execution ux flow Issue created by wild-endeavor Motivation: Why do you think this is important? Improve UX for FlyteRemote workflow executions. Currently after calling

remote.fetch_workflow_execution()

you get back a

FlyteWorkflowExecution

instance. The data model backing this object mirrors the responses returned by Admin which was a good first start but we should improve the ux flow for humans. Goal: What should the final outcome look like, ideally? Rather than

we = remote.fetch_workflow_execution()
we.node_executions

the user should be able to do

we.nodes  # to get a map of the nodes in the execution
we.nodes["n1"]  # to get a node
we.nodes["n1"].execution.tasks
we.nodes["n1"].execution.subs??

For a more complicated example, let's say we have

@workflow
def my_wf(val: int) -> int:
    result = square(val=val)
    return result

@dynamic
def run_subwfs() -> typing.Tuple[int, int]:
    x = my_wf(val=5)
    y = my_wf(val=7)
    return x, y


@workflow
def run_subwfs_wf() -> typing.Tuple[int, int]:
    return run_subwfs()

If we ran

run_subwfs_wf

and fetched the execution for it, we'd be able to navigate it like so:

we = r.fetch_workflow_execution()

we.nodes["n0"].kind <- pattern matches

# normal task
we.nodes["n0"].task.executions

# static subwf
we.nodes["n0"].workflow
we.nodes["n0"].workflow.nodes

# static lp
we.nodes["n0"].child_execution

# dynamic
we.nodes["n0"].dynamic.task.executions
we.nodes["n0"].dynamic.workflow.nodes

# branch
we.nodes["n0"].branch.conditions[0].node # really the node execution, .state
we.nodes["n0"].branch.conditions[0].expression  # result or expression

consider FlyteNode -> FlyteNodeExecution Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte