When you remove or change a node's output, the scheduling dependencies between that node and its downstream nodes break. This page explains which operations trigger an output change, what happens to descendant nodes in each scenario, and how to restore broken dependencies.
Node outputs control scheduling dependencies only — they do not determine whether a node generates table data. The node code alone determines what data is produced.
Before you remove a node output
Check whether the node has descendant nodes. If it does, evaluate the downstream impact first:
-
If descendant nodes depend only on that node, they become isolated nodes and cannot be scheduled. See Scenario 2: Node isolation.
-
If you remove the output before the output table is generated, data quality issues may occur.
When you remove the output of a node that has descendant nodes, a prompt appears in the DataWorks console. Review the downstream impact before proceeding.
Operations that trigger an output change
When you create a node, the system automatically generates two outputs. You can also add outputs manually or use the automatic parsing feature to add the table generated by the node as its output.
The following operations remove or change a node's output:
| Operation | Description |
|---|---|
| Manual removal | You explicitly remove an output from the node. |
| Disabling automatic parsing without reviewing outputs | If the node code changes and a corresponding output is no longer checked, the node no longer generates the table that matched the removed output. |
If a node has no descendant nodes, you can safely remove the output. If it has descendant nodes, evaluate the downstream impact before proceeding.
Downstream impact by dependency type
The following table shows what happens to descendant nodes based on how they depend on the changed node:
| Descendant node dependency | Impact |
|---|---|
| Depends only on the changed node | Becomes an isolated node; cannot be scheduled |
| Depends on the changed node and other nodes | Can still be scheduled, but may fail to get the required data |
Fix broken dependencies when the source node changes
If business changes cause a table to be generated by a different node, identify the new source node and configure new scheduling dependencies for all affected descendant nodes.
Use the automatic parsing feature to reconfigure dependencies: add the table as an output of the new source node. The system then builds the scheduling dependency between the new source and the descendant nodes automatically.
Example: Fix broken dependencies when a node stops generating a table
In this example, Node_A generates Table A, and Node_B depends on Table A. The system configures the Node_A → Node_B dependency using the automatic parsing feature. A business change moves Table A generation to Node_C, breaking the existing dependency.
Step 1: The system configures the Node_A → Node_B dependency via automatic parsing.
Step 2: Node_A no longer generates Table A due to business changes. The Node_A → Node_B dependency becomes invalid.
At this point, the impact on Node_B depends on its dependency configuration:
-
If
Node_Bdepends only onNode_A:Node_Bbecomes an isolated node and cannot be scheduled. -
If
Node_Bdepends on another node as well:Node_Bcan still be scheduled, but may fail to get the data from Table A. TheSELECTstatement inNode_B's code still references Table A, but the node that generates Table A is not necessarily run beforeNode_B.
The error you see on Node_B:
| Field | Detail |
|---|---|
| Error | No ancestor node ID or ancestor node name is specified for Node_B. |
| Cause | Node_B cannot find the node that generates Table A based on the output name of its ancestor node. |
| Root cause | Node_A no longer generates Table A, so the output name no longer resolves to a valid upstream source. |
Step 3: Add Table A as an output of Node_C. The system then configures the Node_C → Node_B dependency via automatic parsing. Commit and deploy Node_C to activate the new dependency.
