Periodic scheduling in DataWorks can break down in two specific ways: a node dependency loop, where a circular dependency prevents any node in the chain from running, and node isolation, where a node loses all its ancestor nodes and can no longer be scheduled automatically. This topic explains what causes each scenario and how to fix it.
Scenario 1: Node dependency loop
How it forms
A node dependency loop occurs when a node is both an ancestor of other nodes and, directly or indirectly, depends on one or more of its own descendant nodes. The result is a circular dependency: no node can start because each one is waiting for another in the same cycle.
Example: Node A reads data from Table C and writes results to Table A. Node B cleanses Table A and writes to Table B. Node C cleanses Table B and writes back to Table C. Because Node A depends on output from Node C—which itself depends on Node A—the three nodes form a loop.
Solution
Analyze the workflow and remove the dependency that creates the loop.
If the ancestor node genuinely needs data produced by its descendant node, configure cross-cycle scheduling dependencies so the ancestor node reads from the *previous* scheduling cycle's output instead of the current one. In the example above, configure a cross-cycle scheduling dependency between Node A and Node C.
Monitoring and alerting
DataWorks scans auto triggered tasks for dependency loops at 09:00, 12:00, 16:00, 20:00, and 22:00 every day. When a loop is detected, an alert notification is sent to the node owner by text message or email.
If a loop forms within 10 minutes before a scheduled scan, it falls outside that scan's detection window and is picked up by the next scan.
Alert rules for node dependency loops are built-in DataWorks rules. To change who receives alert notifications, update the alert contact on the Rule Management page. For details, see Create a custom alert rule.
Scenario 2: Node isolation
What is an isolated node
An isolated node is an auto triggered node that has no ancestor nodes. Without ancestor nodes, DataWorks cannot schedule the node automatically—and any downstream nodes that depend on it are also affected.
In DataWorks, every auto triggered node except the workspace root node must have at least one ancestor node. A node without ancestor nodes cannot run on its scheduled time.
To check whether a node is isolated, right-click it on the Auto Triggered Nodes or Auto Triggered Instances page and select Show Ancestor Nodes. If no ancestor nodes appear, the node is isolated.
Why a node becomes isolated
Before you fix an isolated node, identify which of the following conditions caused the isolation. Five conditions can turn an auto triggered node into an isolated node.
| Cause | What happens | Fix |
|---|---|---|
| Ancestor and descendant nodes have different instance generation modes | A newly created node with Instance Generation Mode set to Immediately After Deployment depends on another newly created node set to Next Day. Because no instance is generated for the ancestor on the current day, the dependent node becomes isolated. | Change the ancestor node's Instance Generation Mode and redeploy it. See Configure different instance generation modes for an auto triggered task and its ancestor task. |
| Ancestor node is outside its validity period | DataWorks generates no instances for nodes that are outside their configured validity period. If a node depends solely on such an ancestor, it becomes isolated. | Update the Effective Period parameter in the Scheduling Time section on the Properties tab of the ancestor node's configuration page. |
| Ancestor node's output changed | When the ancestor node's business logic changes, its outputs change accordingly. This invalidates the existing dependency, leaving the dependent node without an active ancestor. | Reconfigure the scheduling dependencies for the isolated node. |
| Cross-workspace dependency with periodic scheduling disabled | The ancestor node lives in a different workspace where periodic scheduling is not enabled. Without periodic scheduling, the ancestor generates no instances, so the dependent node becomes isolated. Cross-workspace dependencies are more prone to this failure because changes in the remote workspace are not visible locally. | Contact the workspace owner to enable periodic scheduling for that workspace, or remove the cross-workspace dependency. |
| Intermediate task's scheduling time falls outside the backfill time range | Example: Task A (hourly) and Task C (hourly). Task C depends on Task B, Task B depends on Task A. Task B runs daily at 02:00. When you backfill data for Task A and Task C for the 00:00–01:00 time range, no instance is generated for Task B within that range, leaving Task C without an ancestor instance. | Backfill data for the intermediate task within the same time range. In this example, also backfill Task B for 00:00–01:00. See Backfill data and view data backfill instances (new version). |
Monitoring and alerting
DataWorks generates instances for auto triggered nodes every night for the following day's runs. The system scans for isolated nodes at 09:00, 12:00, and 16:00 every day. When an isolated node is detected, an alert notification is sent to the node owner by text message or email.
If a node becomes isolated within 10 minutes before a scheduled scan, it falls outside that scan's detection window and is picked up by the next scan.
Alert rules for isolated nodes are built-in DataWorks rules. To change who receives alert notifications, update the alert contact on the Rule Management page. For details, see Create a custom alert rule.
View isolated nodes
In Operation Center, go to the O&M Dashboard page, open the Workbench Overview tab, and check the Focus On section to see the count and details of all isolated nodes in your workspace.