When a node must wait for data produced or validated in a *previous* scheduling cycle before it can run, configure a cross-cycle dependency. Cross-cycle dependencies let you enforce sequencing across time boundaries — for example, ensuring that data cleansing from yesterday's run succeeds before today's aggregation starts, or that an incremental node never runs ahead of its own previous output.
DataWorks supports three types of cross-cycle dependencies:
| Type | What the current node waits for |
|---|---|
| First-level child nodes | Its own direct downstream nodes to finish in the previous cycle |
| Current node | Its own instance from the previous cycle (self-dependency) |
| Custom | One or more manually specified nodes to finish in the previous cycle |
The auto-parsing feature creates a same-cycle dependency by default. To switch to a cross-cycle dependency, first delete the same-cycle dependency, then add the cross-cycle dependency. For details, see Scheduling dependency logic.
Cross-cycle vs. same-cycle dependencies
These two terms describe *different relationship axes*:
-
A same-cycle dependency links nodes within a single run of the schedule — node B waits for node A to finish in the *same* cycle.
-
A cross-cycle dependency links a node to another node (or to itself) from the *previous* cycle. The two nodes may run in completely different time windows.
Confusing "previous cycle" (cross-cycle) with "upstream" (same-cycle) is a common source of misconfiguration. In the Operation Center, cross-cycle dependencies appear as dashed lines so you can tell them apart from same-cycle dependencies at a glance.
How a dependency blocks execution: If the node that the current instance depends on did not complete successfully in the previous cycle, the current instance is blocked and does not run.
Dependency on previous cycle: First-level child nodes
The current node waits for all its direct downstream nodes to finish successfully in the previous cycle before running in the current cycle.
When to use this: The current node produces output that its downstream nodes cleanse or validate. By waiting for those downstream nodes to succeed in the previous cycle, you confirm that the data from that cycle is clean before processing the next cycle's data. Configure Data Quality rules on the output tables of the downstream nodes to verify that cleansing results meet expectations.
Example: Node A has three downstream nodes: B, C, and D. The current cycle's instance of node A runs only after the previous cycle's instances of B, C, and D all complete successfully.
The following figure shows the dependencies of the nodes in the business flow.
The Operation Center page shows the dependencies of the business flow.
The following figure shows an example of the code for the xc_create node.
The SQL code for the xc_create node creates and populates two tables: xc_1 and xc_2. These tables are set as the node's outputs.
The following figure shows an example of the code for the xc_select node.
The SQL code for the xc_select node queries data from the tables produced by xc_create. The auto-parsing feature automatically identifies xc_create as an upstream dependency for xc_select.
The xc_create node is set to depend on its first-level child nodes.
The Operation Center page shows the dependencies for each node.
Dependency on previous cycle: Current node
The current node instance waits for its own instance from the previous cycle to complete successfully. If the previous instance did not succeed, the current instance is blocked.
When to use this: The node's logic depends on the data it produced in the previous cycle — for example, an incremental aggregation that reads from its own previous output. Configure Data Quality monitoring rules on the node's output table to verify that each cycle's results meet expectations.
Cascading blockage: If one instance fails, every subsequent instance of that node in the same day is also blocked.
Go to Operation Center > Cycle Task > Cycle Instance to view the node's dependencies.
For an hourly node with a self-dependency, if an instance from the previous cycle does not run successfully, the instance for the next hour will not run either. If an hourly task fails or does not run, all subsequent hourly instances of that node for the day are also blocked from running.
Dependency on previous cycle: Custom node
The current node waits for one or more manually specified nodes to finish successfully in the previous cycle, identified by their node IDs.
When to use this: Business logic requires the current node to wait for another pipeline's output, even though the current node's code does not directly read from that pipeline's output table. Enter the ID of the upstream node (for example, 1000374815). To specify multiple nodes, separate the IDs with a comma — for example, 12345,23456.
Example: The xc_create node depends on the successful completion of node 1000374815 from the previous cycle. The xc_create code does not select from the output table of node 1000374815, but the business logic requires that node to complete first.
Node 1000374815 is selected as a custom upstream dependency for the xc_create node.
Go to Operation Center > Cycle Task > Cycle Instance to view the node's dependencies.
Advanced configuration: Do not propagate the dry-run property across cycles
In a branching workflow, only one branch runs while the others are set to dry run. The dry-run property propagates to all child nodes of the skipped branch. If a child node in a skipped branch has a self-dependency (Current node), and that branch is skipped in the previous cycle, the node is set to dry run indefinitely — it can never run because it is always waiting for a previous-cycle instance that was itself a dry run.
For example, if the node I_am_the_left_one is set to dry run, its downstream nodes are also set to dry run.
To ensure that a node's run status in the next cycle is determined by the branch selection in the next cycle — not by the dry-run property inherited from the previous cycle — enable the Do not propagate the dry-run property of ancestor nodes across cycles attribute:
-
On the right side of the node editor page, click Scheduling Configuration.
-
In the Time Property area, select Dependency on previous cycle.
-
Click Advanced Configuration.
-
Select Do not propagate the dry-run property of ancestor nodes across cycles.
This option only applies to the dry-run property propagated from an unselected ancestor branch node. It does not affect the dry-run property of a regular node from the previous cycle.
Typical scenarios
The following table maps common scheduling problems to the recommended cross-cycle dependency solution.
| Scenario | Problem | Solution |
|---|---|---|
| Daily node depends on hourly nodes, but should not wait for all 24 instances | The daily node must start at a fixed time (for example, 12:00), not after all hourly instances finish. | Configure the upstream hourly node with Dependency on previous cycle: Current node (self-dependency). Set the daily node's scheduled time to 12:00. The daily node starts as soon as the 12:00 instance of the hourly node runs successfully. No cross-cycle dependency is needed on the daily node. |
| Daily node depends on the previous day's data from an hourly node | The daily node must use data produced by a specific hourly node from the previous day. | Configure the daily node with Dependency on previous cycle: Custom, and enter the ID of the upstream hourly node. |
| Hourly node depends on a daily node; multiple hourly instances risk running concurrently | When the upstream daily node finishes, several scheduled times for the downstream hourly node have already passed. Multiple instances may start concurrently. | Configure the downstream hourly node with Dependency on previous cycle: Current node (self-dependency). This forces instances to run sequentially. |
| A node depends on the data it generated in the previous epoch | The node's logic reads from its own previous output, and you need to confirm the data generation time before running the next instance. | Configure the node with Dependency on previous cycle: Current node (self-dependency). |
When you unpublish a node, delete all its dependencies — both cross-cycle dependencies (①) and same-cycle dependencies (②).
