A Lakeflow Job has six tasks arranged as a chain of dependencies. In the run detail for last night's run, the task graph shows the third task in a failed state, while the two tasks below it are greyed out and reported as skipped because an upstream dependency did not succeed. An on-call engineer must decide where to look for the fault. Which reading of that run is correct?
- AEach skipped task met an error of its own, so the engineer should read the logs of all three tasks together before deciding what broke the run.
- BThe failed state was propagated up the graph from a task below it, so the fault sits downstream and the third task's own logs will be empty.
- CThe failed task is the one that ran and errored, so its logs carry the fault, while the skipped tasks were never dispatched and hold no output of their own. Correct
- DAll six tasks executed, and the two greyed out tasks finished with warnings, so their target tables may hold partly written output from the run.
Why A is wrong: Tempting because a run that ends unsuccessfully colours several tasks at once in the graph, but a skipped task was never dispatched to compute, so it met no error and wrote no logs of its own.
Why B is wrong: Tempting because status does travel between tasks, but it travels downstream from a dependency to its dependants, never upstream, and a failed task always has logs from its own attempt.
Why C is correct: Correct: Lakeflow Jobs marks a task skipped when a dependency did not satisfy its Run if condition, so the failed task is the single place the run's cause is recorded.
Why D is wrong: Tempting because greyed styling can read as a degraded finish, but skipped is a distinct terminal state meaning the task never started, so it wrote nothing to its targets.