In an orchestrated pipeline with a conditional branch, why does a skipped task also skip everything downstream?

## Three terminal states, not two People think in terms of pass and fail. Orchestrators need a third outcome: **skipped**, meaning the task was deliberately not run because it does not apply to this run. It is not a failure — nothing broke — and it is not a success, because the task produced nothing. Conditional branching is built on that state. A decision task evaluates a condition and the paths not chosen are marked skipped rather than left pending, which is what allows the run to reach a terminal state at all: an untaken branch that stayed pending forever would mean the run never finishes. ## Why the skip cascades Every task's eligibility is decided by a policy over its upstreams' terminal states, and the default policy is *all upstreams succeeded*. A skipped parent fails that test just as surely as a failed one does — for a different reason, but with the same effect. So the child skips, its children skip, and the entire subtree beneath the untaken branch is marked skipped without anyone writing a rule for it. This is the correct behaviour. If you take the full-refresh path, you do not want the three incremental-load tasks running "just in case", and you certainly do not want them sitting pending and blocking completion. ## The join-after-a-branch trap Now put a task after both branches — a publish step, a notification, a metrics refresh — under the default policy. On a full-refresh run, the incremental branch is skipped; on an incremental run, the full branch is skipped. Either way one of the join's parents is skipped, so the join is never eligible and never runs. The pipeline reports a state that looks unremarkable, and the publish silently never happens. The fix is to give the join a policy that treats **skipped as acceptable while failure is not**: run if none of the upstreams failed. Then the join fires on either path but is still blocked by a genuine error. Choosing the fully permissive all-finished policy instead would make the join run even when the taken branch failed, which reintroduces the silent-partial-output problem. ## Skip is not failure, and must not be treated as one Alerting rules that fire on "task did not succeed" will page on every skipped task, which on a branching pipeline is most of the graph. Skips must be filtered out of failure alerting. But there is a second-order risk, and this is the senior point: **a skip can hide a missing output.** If the branch that publishes today's mart is skipped because a condition was mis-evaluated, no task failed, no alert fired, and the mart is simply stale. Task-level state cannot catch this. The defence is a freshness or completeness check on the *output* — "the mart must have a partition for this window" — which fails loudly whether the cause was a failure, a skip, or a pipeline nobody triggered. ## Determinism of the decision A branch decision should be a pure function of the run's own inputs: the data interval, the run parameters, a value read from a table as of that interval. When the condition is computed from `now()`, from a mutable config file, or from a flag a human toggles, the same run re-executed later takes a different path — and reproducing an incident becomes guesswork. Two practices help: - Record the decision as run metadata or as a column on the output, so you can see later which path a given window took. - Prefer decisions that are recoverable: if the branch chose "skip today's load because the source was empty", write a marker recording that emptiness rather than leaving an ambiguous gap. Otherwise a missing partition means either "no data" or "never ran" and you cannot tell which. ## Alternatives to branching Branching is not always the best tool. Two alternatives keep the graph shape constant, which makes runs comparable: - **Make the task itself a no-op** when it does not apply — it runs, finds nothing to do, and succeeds. The graph is uniform and the join needs no special policy. Best when the check is cheap. - **Push the condition into the data**, filtering rows rather than choosing tasks. Often the incremental-versus-full distinction is a predicate, not a topology. Use a real branch when the two paths do materially different work with different costs — spinning up a large cluster for a full rebuild versus a small incremental job — and when running the wrong one has real cost. ## Reruns and skipped subtrees When you rerun a window, remember that clearing a skipped task does not necessarily make it run: it becomes eligible only if the branch decision, re-evaluated, now selects it. If you actually want the other path, you change the inputs or the parameter that drives the decision, not the state of the individual task. This is another reason the decision must be an explicit function of run parameters rather than hidden inside opaque logic. ## Interview framing Say: skipped is a third terminal state; the default eligibility rule is all-succeeded; therefore skip cascades; therefore the join needs a policy accepting skips but not failures. Then add the operational half — skips must not page, but the outputs they were supposed to produce still need a freshness check — and you have answered at senior depth.