[Fix-18448][ui] Fix releaseState undefined access in dag computed properties

[nanxiuzi]

Was this PR generated or assisted by AI?

YES. The fix (replacing props.definition!.workflowDefinition.releaseState with props.definition?.workflowDefinition?.releaseState in two computed properties) was suggested by an AI assistant (Claude). The bug analysis, root cause identification, reproduction, and verification were done manually by the PR author.

Purpose of the pull request

Fixes #18448

When clicking "Edit" on a task node in the DAG editor, the browser console throws Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'releaseState') and the page stops rendering. Two computed properties in dag/index.tsx (startDisplay and menuDisplay) access props.definition.workflowDefinition.releaseState without null-checking workflowDefinition. When workflowDefinition is undefined (e.g., the workflow is in a draft state, the definition was deleted but task instances still reference it, or the API response is missing the field), the access throws and breaks the DAG editor page.

Brief change log

• dolphinscheduler-ui/src/views/projects/workflow/components/dag/index.tsx: replace props.definition!.workflowDefinition.releaseState with props.definition?.workflowDefinition?.releaseState in two computed properties (startDisplay at line 130, menuDisplay at line 152).

This matches the safe pattern already used in dag-toolbar.tsx (lines 276 and 512): props.definition?.workflowDefinition?.releaseState. No behavior change when workflowDefinition is defined — only the previously-crashing case now returns false (the same value the else branches already return).

Verify this pull request

This pull request is code cleanup without any test coverage.

Manually verified the change by testing locally:

• pnpm run build:prod passes (vue-tsc type check + Vite production build).
• On a 3.4.2 deployment, previously clicking "Edit" on a task in the affected state produced Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'releaseState') in the browser console and the DAG page stopped rendering. With this fix, the page renders normally; the start button and "other" menu are hidden in the right-click menu when workflowDefinition is undefined, which is the correct behavior since the user cannot meaningfully start/operate on a workflow without a workflowDefinition.

Pull Request Notice

Pull Request Notice

[SbloodyS]

You should follow the PR template and fill in the form.

[nanxiuzi]

@SbloodyS Thanks for the feedback. I've updated the PR description to follow the official PR template (AI assistance declaration, Purpose, Brief change log, Verify, Pull Request Notice). Please take another look when you have time.

[SbloodyS]

This patch does not address a demonstrated reachable state

workflowDefinition is not optional when definition is present in the current page flows:

• The workflow creation page does not pass definition, so the existing if (props.definition) branch already returns false.
• The workflow-definition detail page accesses res.workflowDefinition.releaseState before assigning the response to definition and rendering the DAG. A response without workflowDefinition would fail there first.
• The workflow-instance detail page accesses res.dagData.workflowDefinition.locations before assigning res.dagData to definition. It would also fail before reaching these computed properties.
• On the backend, the workflow-instance query throws when the referenced workflow definition does not exist, and successful DAG responses are built with that non-null definition.

Therefore, the draft, deleted-definition, and missing-response-field scenarios described in the PR cannot reach these two changed lines with a truthy props.definition and an undefined nested workflowDefinition.

Adding optional chaining here only hides one invalid state and renders a partially functional page, while other code still relies on the same required field. It does not identify or fix the producer of the malformed object.

Please provide the exact route, API response, and reproducible steps that reach this state. If a real code path creates { workflowDefinition: undefined, ... }, that producer should be fixed. If the field is intentionally optional, the type and the page-level loading/error handling should be updated consistently, with a regression test covering the complete flow.