#3439 [BUG] [Graph] Cannot read properties of null/undefined for workflows referencing launch plans Issue created by MorpheusXAUT We're currently seeing two variants of what appears to be an issue similar to flyteorg/flyteconsole#378: error1 error2 The first error encountered was the one reported by our developers, the second one was my attempt to reproduce this issue in a sample workflow. Both errors were encountered using flyteconsole

v1.1.7

. I believe the culprit to be launch plan references in workflows with at least one other sub-workflow called. I've used the launchplan example from the Flyte docs to reproduce the issue. The following workflow caused the second error message:

import calendar
import datetime

from flytekit import dynamic, task, workflow, LaunchPlan


@task
def greet(day_of_week: str, number: int, am: bool) -> str:
    greeting = "Have a great " + day_of_week + " "
    greeting += "morning" if am else "evening"
    return greeting + "!" * number


@workflow
def go_greet(day_of_week: str, number: int, am: bool = False) -> str:
    return greet(day_of_week=day_of_week, number=number, am=am)


morning_greeting = LaunchPlan.create(
    "morning_greeting",
    go_greet,
    fixed_inputs={"am": True},
    default_inputs={"number": 1},
)


@workflow
def test_flyteconsole_graph_launchplanref() -> None:
    go_greet(day_of_week="Monday", number=1, am=True) # Important, workflow must have sub-workflows!

    today = datetime.datetime.today()
    for n in range(7):
        day = today + datetime.timedelta(days=n)
        weekday = calendar.day_name[day.weekday()]
        if day.weekday() < 5:
            print(morning_greeting(day_of_week=weekday))
        else:
            print(morning_greeting(number=3, day_of_week=weekday))

If I remove the first line from

test_flyteconsole_graph_launchplanref

(and thus don't have any other sub-workflows), the graph renders just fine. Our production workflow produces the following stacktrace:

TypeError: Cannot read properties of null (reading 'resourceType')
    at t.checkIfObjectsAreSame (main-56c8d9de.js:1:349519)
    at t.getSubWorkflowFromId (main-56c8d9de.js:1:350236)
    at m (main-56c8d9de.js:1:347158)
    at p (main-56c8d9de.js:1:347537)
    at f (main-56c8d9de.js:1:348547)
    at m (main-56c8d9de.js:1:347200)
    at p (main-56c8d9de.js:1:347537)
    at f (main-56c8d9de.js:1:348589)
    at t.transformerWorkflowToDag (main-56c8d9de.js:1:348639)
    at main-56c8d9de.js:1:345223

The actual stack trace displayed in my reproduction attempt leads to a slightly different place when accessing the graph:

TypeError: Cannot read properties of undefined (reading 'n0-0-n0')
    at main-56c8d9de.js:1:344707
    at t.WorkflowGraph (main-56c8d9de.js:1:344858)
    at we (react-dom.production.min.js:84:293)
    at zj (react-dom.production.min.js:226:496)
    at Th (react-dom.production.min.js:152:223)
    at tj (react-dom.production.min.js:152:152)
    at Te (react-dom.production.min.js:146:151)
    at react-dom.production.min.js:61:68
    at unstable_runWithPriority (react.production.min.js:25:260)
    at Da (react-dom.production.min.js:60:280)

Interestingly enough, the "Nodes" tab is already partially broken though: error3 The stack trace printed when loading the nodes points to the same location as our production workflow. It seems to me that

parseNode

in

components/WorkflowGraph/transformerWorkflowToDag.tsx

only seems to handle `subworkflowRefs`, but not

launchplanRefs

, thus passing on

null

as

id

to `getSubWorkflowFromId` and subsequently `checkIfObjectsAreSame`. The nodes causing the crash have no

subworkflowRefs

, but a

launchplanRef

instead, according to my hastily slapped on debug logging: launchplanRef If the workflow executed doesn't have any sub-workflows, we're not running into this issue as the comparison containing `checkIfObjectsAreSame` is not run at all. I was able to "fix" this by having

checkIfObjectsAreSame

check for `null`/`undefined` before its `for` loop:

export const checkIfObjectsAreSame = (a, b) => {
  if ((!a && b) || (a && !b)) {
    return false;
  } else if (!a && !b) {
    return true;
  }
  for (const k in a) {
    if (a[k] !== b[k]) {
      return false;
    }
  }
  return true;
};

Above change "fixes" the graphs (and nodes view), however I feel like that's only halfway to solving the actual issue 😅 Would that additional check be enough in this case (if so, I can open a tiny PR, if you'd like), or must

parseNode

handle the

launchplanRefs

as well? I'm happy to help with further testing/development if so desired, but would appreciate some pointers on how to best proceed 🙂 flyteorg/flyte