[BUG] Console crashes with "Cannot destructure property 'type'" when a node execution's inputs don't match the resolved task interface

[guozhans]

Describe the bug

Opening an execution's details view in the console can crash the entire page with the error boundary:

Unexpected error
TypeError: Cannot destructure property 'type' of 't[a]' as it is undefined.

In our case this happens reliably when navigating to a (parent) execution that contains a dynamic node whose children launch child executions: following the Parent link from a child execution to that parent execution shows the error page instead of the execution view.

Root cause

The only code that can throw this is literalsToLiteralValueMap in packages/oss-console/src/components/Launch/LaunchForm/utils.ts (line 236 on v1.20.1, unchanged on current master):

for (let i = 0; i < Object.keys(literals).length; i++) {
  const name = Object.keys(literals)[i];
  const { type } = nameToTypeMap[name];   // ← throws when `name` is not in the map
  ...
}

It iterates over the node execution's actual input literals (fullInputs.literals) and looks each key up in the resolved task template's interface.inputs.variables. If the execution data contains any input key that the resolved interface does not declare — e.g. for dynamic-node children where the template resolution can pick a template whose interface doesn't match, or tasks re-registered with a changed signature — the lookup returns undefined and the destructure throws.

The callers (ExecutionDetailsActions/RerunButton.tsx, ExecutionDetailsActions/ResumeButton.tsx, and the table-row equivalents under Executions/Tables/NodeExecutionActions/) run this while rendering — in ExecutionDetailsActions/RerunButton.tsx the data query is not gated behind the button click, so the exception escapes to the page error boundary and takes down the whole execution view. A mismatched node should at worst degrade the Rerun pre-fill, not make the execution unviewable.

Expected behavior

The execution details view renders; input keys unknown to the resolved interface are skipped (or the Rerun form falls back to empty initial values). Suggested minimal fix:

const variable = nameToTypeMap[name];
if (!variable) continue;   // don't crash the page on interface mismatch
const { type } = variable;

Happy to send a PR for this.

Additional context to reproduce

1. Have an execution where any node execution's fullInputs.literals contains a key not present in the task template interface the console resolves for that node (we hit it via a dynamic node launching child executions; clicking the child's Parent link navigates to the affected parent execution).
2. Open that execution's details page in the console → error boundary with the TypeError above.

Flyte & Flytekit version

• flyteconsole v1.20.1 (flyte-core Helm chart; flyteadmin/flytepropeller v1.16.4)
• The affected code path is unchanged on flyteconsole master.

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[runllm]

It could be possible that the root cause is a missing guard in the Flyte Console code, specifically in literalsToLiteralValueMap, where it assumes every input literal key exists in the resolved task interface. When this is not true (e.g., dynamic nodes or interface changes), destructuring fails and crashes the page. A minimal fix might be to skip unknown keys, as you suggested, by checking if the variable exists before destructuring its type. This would prevent the crash and allow the UI to degrade gracefully, possibly leaving the rerun form with empty values for those keys. The relevant code is at utils.ts line 236.

Though I'm not entirely certain, it might be that this issue is not explicitly addressed in the current Flyte Console codebase, and your proposed fix aligns with best practices for defensive coding in dynamic interfaces. Would you like a step-by-step breakdown of how to implement and test this fix?

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @Herald to ask follow-up questions. See runllm.com for more!

[PushpakAg]

Looks like the issue arises from a mismatch between node execution inputs and the task interface, causing a crash. I'd check the handling of undefined variables in literalsToLiteralValueMap.